Hi,
Summer is here on the East Coast of North America and that means another edition of Bits from PureOS. And no, I wasn't eaten by a shark last week on Cape Cod, but thanks for asking.
To reiterate, the long-running topics we're responsible for are;
1. Reproducible builds 2. Supporting Pureboot and Purism hardware 3. Continuous delivery of PureOS 4. PureOS store (and application discovery)
To that list I think we ought to add;
5. PureOS Security 6. Additional packages for PureOS
We have already a security mailing list here: https://lists.puri.sm/listinfo/security We should likely develop a plan for its use. Other security topics perhaps ought to be discussed privately and I intend to kick off the topic with stakeholders.
On the reproducible builds front you can follow the thread here; https://lists.puri.sm/pipermail/pureos-project/2019-July/000177.html What is happening is we're trying to adjust various time stamps that various tools insert into a given build. Those time stamps vary between builds (of course, because any two builds occur at different times). Lamby has patched many of the tools and I'm trying to find the right context to inform the tools that they're to use the standardised time stamp.
Discussion with various folks has led us to cease maintaining PureBrowser. The reasons are pretty simple; we are investing in the GNOME ecosystem and GNOME web runs as a flatpak bringing in a bit of isolation to the browser which adds an additional layer of security. I think that we should make an announcement about this going forward in various places since there is often much discussion on browsers in our forums.
Upcoming discussions on how to seed a build of PureOS for the L5 should be interesting, I plan to send out an invitation for discussing this in the next day or so. More info to come.
Lastly, getting apps into PureOS needs to be better documented. I'm doing some packaging but am struggling with getting pbuilder to play nicely with my requests to pull in older versions of software. If we had clear instructions on how to build a PureOS image for pbuilder that would help me immensely. I'll reach out to folks regarding this since I'm certain that the knowledge needed is available. Also, uploads to Laniakea of certain packages are failing occasionally, something Guido has pointed out. We ought to speak with him to determine what the issues are and to smooth out the upload process.
As always, feedback most welcome.
Dear all,
Thanks so much again for taking the time to pen this Jeremiah. Yet again it is extremely and surprisingly useful to get such summary updates.
Other security topics perhaps ought to be discussed privately and I intend to kick off the topic with stakeholders.
A quick thought: whilst the specific details of this might be more suitable for some initial discussions to be held «in camera» would it be appropriate to briefly outline the very approximate areas in a security or politically sensitive way?
I've often found this helps prevent mishaps (or even wasted effort) in that someone can throw some potentially salient or relevant factoid in the right direction, particular regarding upcoming or very-recent changes elsewhere in the free software world. After all, since the release of Buster, Debian is very much in a fun state of flux.
we should make an announcement about [Purebrowser] going forward in various places since there is often much discussion on browsers in our forums.
Indeed, having any canonical location for this decision (it doesn't have to be a big "splash" I suppose, just whatever is easiest..) would certainly help centralise and make that info more discoverable. Being proactive versus reactive, etc. etc.
If we had clear instructions on how to build a PureOS image for pbuilder that would help me immensely.
Sooo, I have some dirty scripts to make a (sorry!) Docker image of PureOS for my own use / builds which could be used to kick this off. I'm not very learned in the subtle and dark arts of pbuilder so that might be mostly a link/information dump at this time, alas.
Anyway, thanks again for posting this. You find me a bit fatigued from 14/15 days of DebConf so do please excuse me short and snappy response... but at least this way it will be relatively timely..
Best wishes,
Hi, On Tue, Jul 30, 2019 at 09:50:47AM -0300, Chris Lamb wrote: [..snip..]
Sooo, I have some dirty scripts to make a (sorry!) Docker image of PureOS for my own use / builds which could be used to kick this off. I'm not very learned in the subtle and dark arts of pbuilder so that might be mostly a link/information dump at this time, alas.
Here's another way to create docker images for pureos based on what the debian docker images on dockerhub use:
https://github.com/debuerreotype/debuerreotype/pull/63
Cheers, -- Guido
Am Di., 30. Juli 2019 um 15:15 Uhr schrieb Guido Günther guido.gunther@puri.sm:
Hi, On Tue, Jul 30, 2019 at 09:50:47AM -0300, Chris Lamb wrote: [..snip..]
Sooo, I have some dirty scripts to make a (sorry!) Docker image of PureOS for my own use / builds which could be used to kick this off. I'm not very learned in the subtle and dark arts of pbuilder so that might be mostly a link/information dump at this time, alas.
Here's another way to create docker images for pureos based on what the debian docker images on dockerhub use:
https://github.com/debuerreotype/debuerreotype/pull/63
Or build stuff with debspawn: ``` $ debspawn create landing $ debspawn build landing /path/to/dsc/or/package/source/directory/ ```
The possibilities are endless! :-)
On Tue, 2019-07-30 at 09:50 -0300, Chris Lamb wrote:
Dear all,
[..]
Other security topics perhaps ought to be discussed privately and I intend to kick off the topic with stakeholders.
A quick thought: whilst the specific details of this might be more suitable for some initial discussions to be held «in camera» would it be appropriate to briefly outline the very approximate areas in a security or politically sensitive way?
Yes, I think so. Thanks for the suggestion. A high-level outline of topics I'd like to see addressed are;
1. How will we use the Security mailing list we now have? Is it to be used in the same manner as the Debian Security list? Or are we going to address PureOS specific security issues? What are the expecatations for embargos (if any)?
2. Do we have a policy for server setup with regard to authentication and authorization? Examples: no root ssh logins, password-less logins, ssh key size and cipher, etc. These policies are meant for the PureOS infrastructure which hopefully will not host user data (so no immediate need for GDPR audit, etc.)
I welcome other input, this is what comes to mind at the moment.
Regards,
Jeremiah
Am Mo., 29. Juli 2019 um 02:33 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
[...] Also, uploads to Laniakea of certain packages are failing occasionally, something Guido has pointed out. We ought to speak with him to determine what the issues are and to smooth out the upload process.
All of the issues were in the uploaded packages so far (except for one sshfs mount issue months ago). The responsible component for handling uploads is dak (the Debian Archive Kit), which was sometimes giving less helpful messages, like the "No data." error recently when the .dsc file of the upload wasn't signed for some reason. I am very confident that all of these issues will go away once we have an automated pipeline for uploading :-)
The more pressing issue that we need to decide ASAP though is how we handle the PureOS-based-on-Debian-stable flavor of PureOS. I didn't actually receive that much feedback on the proposed solutions, and I don't want to just go ahead with the solution I like best without knowing that people agree with that, or some discussion about it first. Meanwhile though, our current users receive no updates in the green suite, which isn't a good state to be in.
Cheers, Matthias
On Tue, 2019-07-30 at 16:59 +0200, Matthias Klumpp wrote:
Am Mo., 29. Juli 2019 um 02:33 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
[...] Also, uploads to Laniakea of certain packages are failing occasionally, something Guido has pointed out. We ought to speak with him to determine what the issues are and to smooth out the upload process.
All of the issues were in the uploaded packages so far (except for one sshfs mount issue months ago). The responsible component for handling uploads is dak (the Debian Archive Kit), which was sometimes giving less helpful messages, like the "No data." error recently when the .dsc file of the upload wasn't signed for some reason. I am very confident that all of these issues will go away once we have an automated pipeline for uploading :-)
An automated pipeline you say? Tell me more. ;-)
The more pressing issue that we need to decide ASAP though is how we handle the PureOS-based-on-Debian-stable flavor of PureOS. I didn't actually receive that much feedback on the proposed solutions, and I don't want to just go ahead with the solution I like best without knowing that people agree with that, or some discussion about it first. Meanwhile though, our current users receive no updates in the green suite, which isn't a good state to be in.
It's not a good state to be in, I think everyone agrees. Let's try and have a bias towards action, largely because if we move forward with a given approach and it breaks, we can change it. Yes, that may be difficult and messy (maybe not) but it is likely better than leaving current green users without a best-effort approach to security by bringing in Buster updates.
So, I'll express my preference here: green remains stable, we create a new 'amber' rolling release.
The consequences are;
- We need to assign resources to update green with the security and other updates from Debian. If you were to give me a login to Laniakea Matthias I can go about documenting the process with your help. I can be the resource for now and when there are other resources available, we can add them.
- We need to create the new amber release and document to our users how they may upgrade to that in their sources list.
Regards,
Jeremiah
Am Di., 30. Juli 2019 um 19:19 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
[...]
It's not a good state to be in, I think everyone agrees. Let's try and have a bias towards action, largely because if we move forward with a given approach and it breaks, we can change it. Yes, that may be difficult and messy (maybe not) but it is likely better than leaving current green users without a best-effort approach to security by bringing in Buster updates.
So, I'll express my preference here: green remains stable, we create a new 'amber' rolling release.
The consequences are;
- We need to assign resources to update green with the security and
other updates from Debian. If you were to give me a login to Laniakea Matthias I can go about documenting the process with your help. I can be the resource for now and when there are other resources available, we can add them.
- We need to create the new amber release and document to our users how
they may upgrade to that in their sources list.
The more severe consequences of going with that (essentially option B from https://lists.puri.sm/pipermail/pureos-project/2019-July/000167.html ) is that we need to hack the user's sources.list somehow in order to support this scenario. Or go with option A which is inflexible and risky, by not having -updates/-security suites and uploading everything to an unfrozen green suite directly. If we indeed freeze green, those questions must be answered first and implemented, otherwise our users of green would *still* not receive any more updates.
Cheers, Matthias
On Tue, 2019-07-30 at 19:52 +0200, Matthias Klumpp wrote:
Am Di., 30. Juli 2019 um 19:19 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
[...]
It's not a good state to be in, I think everyone agrees. Let's try and have a bias towards action, largely because if we move forward with a given approach and it breaks, we can change it. Yes, that may be difficult and messy (maybe not) but it is likely better than leaving current green users without a best-effort approach to security by bringing in Buster updates.
So, I'll express my preference here: green remains stable, we create a new 'amber' rolling release.
The consequences are;
- We need to assign resources to update green with the security and
other updates from Debian. If you were to give me a login to Laniakea Matthias I can go about documenting the process with your help. I can be the resource for now and when there are other resources available, we can add them.
- We need to create the new amber release and document to our users
how they may upgrade to that in their sources list.
The more severe consequences of going with that (essentially option B from https://lists.puri.sm/pipermail/pureos-project/2019-July/000167.html ) is that we need to hack the user's sources.list somehow in order to support this scenario.
Can we not ask those who want a rolling release to edit /etc/apt/sources.list themselves? This is already explained in various places: https://tracker.pureos.net/w/pureos/software_center/software_sources/
Or go with option A which is inflexible and risky, by not having -updates/-security suites and uploading everything to an unfrozen green suite directly. If we indeed freeze green, those questions must be answered first and implemented, otherwise our users of green would *still* not receive any more updates.
Cheers, Matthias
Am Di., 30. Juli 2019 um 21:09 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
On Tue, 2019-07-30 at 19:52 +0200, Matthias Klumpp wrote:
[...] The more severe consequences of going with that (essentially option B from https://lists.puri.sm/pipermail/pureos-project/2019-July/000167.html ) is that we need to hack the user's sources.list somehow in order to support this scenario.
Can we not ask those who want a rolling release to edit /etc/apt/sources.list themselves? This is already explained in various places: https://tracker.pureos.net/w/pureos/software_center/software_sources/
No, that is not the problem here. The problem is all users of green having only the green suite mentioned in their sources.list, since no -updates or -security suites exist for a rolling-release distribution (and that's what PureOS is currently designed for). So actually, all users of green would have to update their sources.list to still have security updates, which I really don't think is possible if they manually do that - we can't reach every user of green with a blogpost. (that's why we either need to find a way to do that automatically, or just keep green rolling and create a new stable suite that existing users can opt-in instead)
[...]
On Wed, 2019-07-31 at 13:22 +0200, Matthias Klumpp wrote:
Am Di., 30. Juli 2019 um 21:09 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
On Tue, 2019-07-30 at 19:52 +0200, Matthias Klumpp wrote:
[...] The more severe consequences of going with that (essentially option B from https://lists.puri.sm/pipermail/pureos-project/2019-July/000167.html ) is that we need to hack the user's sources.list somehow in order to support this scenario.
Can we not ask those who want a rolling release to edit /etc/apt/sources.list themselves? This is already explained in various places: https://tracker.pureos.net/w/pureos/software_center/software_sources/
No, that is not the problem here. The problem is all users of green having only the green suite mentioned in their sources.list, since no -updates or -security suites exist for a rolling-release distribution (and that's what PureOS is currently designed for). So actually, all users of green would have to update their sources.list to still have security updates, which I really don't think is possible if they manually do that - we can't reach every user of green with a blogpost.
Fair point.
(that's why we either need to find a way to do that automatically,
While this approach is tempting, there be dragons.
or just keep green rolling and create a new stable suite that existing users can opt-in instead)
I'm starting to feel this may be the best alternative. I do worry that there will be a flood of packages coming in however it we go down this path - can we manage that?
Cheers,
Jeremiah
Am Mi., 31. Juli 2019 um 17:09 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
On Wed, 2019-07-31 at 13:22 +0200, Matthias Klumpp wrote:
[...]
Fair point.
(that's why we either need to find a way to do that automatically,
While this approach is tempting, there be dragons.
or just keep green rolling and create a new stable suite that existing users can opt-in instead)
I'm starting to feel this may be the best alternative. I do worry that there will be a flood of packages coming in however it we go down this path - can we manage that?
The "make new stable suite" is my preferred solution, as it is relatively simple, clean and most importantly very safe to do. We can absolutely handle a massive influx of packages from Debian into green, that's no problem. I would create the "amber", "amber.updates" and "amber-security" suites, populate the amber suite with the stuff that's in green, change the distribution release ID for the stable suite in the stable suite (amber) only, adjust the image builder to recognize the new suite and create a few images for that suite. Then we can tell our users to switch to amber now if they want stable or remain on green, and then after a week open the floodgates and sync up green with testing again. New Librems would then ship with amber by default.
In the long run, "green" would be an alias for the next development suite, probably some color starting with "b" ^^
It's quite a bunch of work, but at least nothing will break in the process. The only downside is that existing user of green who don't opt into stable in time will remain on the development branch. But I don't see a non-hacky way to move them to a different branch automatically, and changing green to not mean "rolling release" is tricky.
Cheers, Matthias
On Mon, 2019-08-05 at 19:11 +0200, Matthias Klumpp wrote:
Am Mi., 31. Juli 2019 um 17:09 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
On Wed, 2019-07-31 at 13:22 +0200, Matthias Klumpp wrote:
[...]
Fair point.
(that's why we either need to find a way to do that automatically,
While this approach is tempting, there be dragons.
or just keep green rolling and create a new stable suite that existing users can opt-in instead)
I'm starting to feel this may be the best alternative. I do worry that there will be a flood of packages coming in however it we go down this path - can we manage that?
The "make new stable suite" is my preferred solution, as it is relatively simple, clean and most importantly very safe to do. We can absolutely handle a massive influx of packages from Debian into green, that's no problem. I would create the "amber", "amber.updates" and "amber-security" suites, populate the amber suite with the stuff that's in green, change the distribution release ID for the stable suite in the stable suite (amber) only, adjust the image builder to recognize the new suite and create a few images for that suite. Then we can tell our users to switch to amber now if they want stable or remain on green, and then after a week open the floodgates and sync up green with testing again. New Librems would then ship with amber by default.
In the long run, "green" would be an alias for the next development suite, probably some color starting with "b" ^^
It's quite a bunch of work, but at least nothing will break in the process. The only downside is that existing user of green who don't opt into stable in time will remain on the development branch. But I don't see a non-hacky way to move them to a different branch automatically, and changing green to not mean "rolling release" is tricky.
I agree with everything you wrote. Sorry it took me so long to come around to your way of seeing things, I don't understand the system and the implications as well as you do. But I understand much better now.
I already have a discussion regarding these changes, mostly just a question to the forum users as to whether they prefer a stable or rolling release. I'm surprised by how many forum users prefer stable. https://forums.puri.sm/t/would-you-use-a-pureos-rolling-release-or-do-you-wa...
What can I do to assist you and support you in the work?
Best,
Jeremiah
Am Mo., 5. Aug. 2019 um 19:20 Uhr schrieb Jeremiah C. Foster jeremiah.foster@puri.sm:
[...] I agree with everything you wrote. Sorry it took me so long to come around to your way of seeing things, I don't understand the system and the implications as well as you do. But I understand much better now.
Thanks! I think explaining this stuff is absolutely vital: First because I could make a mistake or there could be a reason I didn't think of which makes another option the much preferred choice, and second to just explain the steps so next time things come up people know about it. FWIW, there *are* reasons to not choose this option (e.g. not wanting to leavy any user behind on green), however I think they are less important compared to the advantages the new-suite option has. I believe that going that route is the right engineering choice.
I already have a discussion regarding these changes, mostly just a question to the forum users as to whether they prefer a stable or rolling release. I'm surprised by how many forum users prefer stable. https://forums.puri.sm/t/would-you-use-a-pureos-rolling-release-or-do-you-wa...
That's actually pretty interesting! I am quite sure when we started PureOS a similar question was asked, and the overwhelming majority wanted a rolling release like Arch Linux (which back then surprised me, as I was in the "make fixed releases" camp).
What can I do to assist you and support you in the work?
The changes to the archive are a sequence of dak commands and SQL queries, which TBH I need to figure out *again* - when we made Tanglu, every new release was an experience of re-learning the same stuff again. This time I will condense the steps into a Laniakea command, so I don't have to remember all that stuff next time - that's the point of having Laniakea afterall. I don't think there is much you could help with in that particular area until the new archive suites are up. The image generator could use some help though: lb config as run in https://source.puri.sm/pureos/infra/make-live/blob/master/auto/config#L158 has arguments to include security/updates suite which we must use, also that same script will need to treat "green" and "amber" differently (with only applying the flags for updates for amber). There is even a chance that the PureOS profile in live-build needs a patch to make that stuff work correctly. That is definitely something where help and testing is needed! Also, once the new suite is up, there are a lot of things that need testing - depending how much I need to change in the archive, we need quite a bit of checks to ensure everything still works correctly.
In any case, we need to get started with this stuff ASAP, but unfortunately I will not have the next two weekends to work on this, so I'll have to do these changes incrementally during the next two weeks. Having a fast feedback loop will be incredibly helpful there - as soon as you notice *anything* weird, just ping me immediately. (I do not anticipate major problems though - splitting out releases was a major pain in Tanglu, but we never really had big problems with it) I'll try to write a Laniakea helper for the necessary steps this time, and also maybe instructions, so others can make releases in future as well.
Cheers, Matthias
Quoting Jeremiah C. Foster (2019-07-29 02:33:16)
Discussion with various folks has led us to cease maintaining PureBrowser.
Did we really "cease maintaining PureBrowser" already?
- Jonas
On Wed, 2019-10-23 at 13:19 +0200, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-07-29 02:33:16)
Discussion with various folks has led us to cease maintaining PureBrowser.
Did we really "cease maintaining PureBrowser" already?
No. The blocker is;
1. A blog post holding the announcement of EoL for PB 2. Consensus from the maintainer (that's you!) of PB that this is what we're going to do
I'm happy to write the blog post. How do you feel ending the PB fork maintenance?
Regards,
Jeremiah
Quoting Jeremiah C. Foster (2019-10-24 18:40:53)
On Wed, 2019-10-23 at 13:19 +0200, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-07-29 02:33:16)
Discussion with various folks has led us to cease maintaining PureBrowser.
Did we really "cease maintaining PureBrowser" already?
No. The blocker is;
- A blog post holding the announcement of EoL for PB
- Consensus from the maintainer (that's you!) of PB that this is what
we're going to do
I'm happy to write the blog post. How do you feel ending the PB fork maintenance?
Thanks, I'd appreciate if you wrote the blog post.
If I were to decide, then I would wanna end PureBrowser fork *now* before next release expected in few weeks, and expected to reintroduce Mozilla- and Google-promoting stuff currently ripped out.
To clarify, I do *not* imply that I consider Epiphany mature enough to fully replace PureBrowser: I expect some users to continue to need a Mozilla-based (or Chromium-based) browser.
I expect users to be grumpy no matter if we drop PureBrowser or keep it.
But am I really the one to decide here? PureBrowser has been promoted as something estraordinary in PureOS, cemented by glueing a couple addons to it. My judgement here does not take that into account.
- Jonas
On Thu, 2019-10-24 at 19:25 +0200, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-10-24 18:40:53)
On Wed, 2019-10-23 at 13:19 +0200, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-07-29 02:33:16)
Discussion with various folks has led us to cease maintaining PureBrowser.
Did we really "cease maintaining PureBrowser" already?
No. The blocker is;
- A blog post holding the announcement of EoL for PB
- Consensus from the maintainer (that's you!) of PB that this is
what we're going to do
I'm happy to write the blog post. How do you feel ending the PB fork maintenance?
Thanks, I'd appreciate if you wrote the blog post.
Will do!
If I were to decide, then I would wanna end PureBrowser fork *now* before next release expected in few weeks, and expected to reintroduce Mozilla- and Google-promoting stuff currently ripped out.
Agreed. This seems like good timing.
To clarify, I do *not* imply that I consider Epiphany mature enough to fully replace PureBrowser: I expect some users to continue to need a Mozilla-based (or Chromium-based) browser.
I think you're likely right here.
I expect users to be grumpy no matter if we drop PureBrowser or keep it.
I expect you're likely correct.
But am I really the one to decide here?
As the maintainer I think you have a key perspective, yes.
PureBrowser has been promoted as something estraordinary in PureOS, cemented by glueing a couple addons to it. My judgement here does not take that into account.
I think that our overall focus has shifted somewhat out of necessity. I think that we focus our efforts a bit lower on the stack as it were, on the Window Manager, Mesa, kernel, BIOS, and even at the hardware level. That is where Purism I think has had the largest impact and where the company differentiates itself from comptetitors. On the software side higher up in the stack, things like PureBrowser take a great deal of effort as you know better than anyone. The effort, especially recently, doesn't seem to be appreciated upstream. When I discussed our changes and our motivations for the changes with Mozilla, they were uninterested in our use case. Also, as we've seen, they make lots of changes which are disruptive to users regardless of whether we rip them out or keep them.
While Epiphany is not in the same place as Firefox in terms of features and usability, we are investing more time and effort there. I think it is time to make the switch.
Best,
Jeremiah
Hi,
On 10/25/19 12:23 AM, Jeremiah C. Foster wrote:
I think that our overall focus has shifted somewhat out of necessity. I think that we focus our efforts a bit lower on the stack as it were, on the Window Manager, Mesa, kernel, BIOS, and even at the hardware level. That is where Purism I think has had the largest impact and where the company differentiates itself from comptetitors. On the software side higher up in the stack, things like PureBrowser take a great deal of effort as you know better than anyone. The effort, especially recently, doesn't seem to be appreciated upstream. When I discussed our changes and our motivations for the changes with Mozilla, they were uninterested in our use case. Also, as we've seen, they make lots of changes which are disruptive to users regardless of whether we rip them out or keep them.
While Epiphany is not in the same place as Firefox in terms of features and usability, we are investing more time and effort there. I think it is time to make the switch.
I agree with that.
The idea is to make a consistent experience between the phone and the laptops. Epiphany is not mature enough yet and needs to be improved but it is already in a state where it can be used on a daily basis.
I made the experience of having Mathilde, my wife, who is not technical at all, to use Epiphany for a couple of weeks on my Librem 15 and she hasn't complained much so far (only about having to adapt to the new UI).
To me, now is the right time to make the switch, as our user base is not too significant. It may change when the phone will get to mass production in a few months.
There will be some unhappy users of course but I think that it is what will push us to invest in Epiphany the right way, to make them happy again. This investment has already started with the development of the phone and now we need to push this software to compete with Firefox and Chrome. This will never happen if nobody uses it.
François
On Fri, 2019-10-25 at 11:15 +0200, François Téchené wrote:
Hi,
On 10/25/19 12:23 AM, Jeremiah C. Foster wrote:
I think that our overall focus has shifted somewhat out of necessity. I think that we focus our efforts a bit lower on the stack as it were, on the Window Manager, Mesa, kernel, BIOS, and even at the hardware level. That is where Purism I think has had the largest impact and where the company differentiates itself from comptetitors. On the software side higher up in the stack, things like PureBrowser take a great deal of effort as you know better than anyone. The effort, especially recently, doesn't seem to be appreciated upstream. When I discussed our changes and our motivations for the changes with Mozilla, they were uninterested in our use case. Also, as we've seen, they make lots of changes which are disruptive to users regardless of whether we rip them out or keep them.
While Epiphany is not in the same place as Firefox in terms of features and usability, we are investing more time and effort there. I think it is time to make the switch.
I agree with that.
The idea is to make a consistent experience between the phone and the laptops. Epiphany is not mature enough yet and needs to be improved but it is already in a state where it can be used on a daily basis.
I made the experience of having Mathilde, my wife, who is not technical at all, to use Epiphany for a couple of weeks on my Librem 15 and she hasn't complained much so far (only about having to adapt to the new UI).
To me, now is the right time to make the switch, as our user base is not too significant. It may change when the phone will get to mass production in a few months.
There will be some unhappy users of course but I think that it is what will push us to invest in Epiphany the right way, to make them happy again. This investment has already started with the development of the phone and now we need to push this software to compete with Firefox and Chrome. This will never happen if nobody uses it.
Thanks Francois - valuable input. Some of this information I'm going to use in the blog post announcing the move. :-)
Also, there's a security issue with the upstream code I've been informed via the Debian Security mailing list and Jonas: https://security-tracker.debian.org/tracker/source-package/firefox-esr
This is going to be a focus in the near term.
Regards,
Jeremiah
Quoting Jeremiah C. Foster (2019-10-25 00:23:32)
On Thu, 2019-10-24 at 19:25 +0200, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-10-24 18:40:53)
On Wed, 2019-10-23 at 13:19 +0200, Jonas Smedegaard wrote:
Quoting Jeremiah C. Foster (2019-07-29 02:33:16)
Discussion with various folks has led us to cease maintaining PureBrowser.
Did we really "cease maintaining PureBrowser" already?
No. The blocker is;
- A blog post holding the announcement of EoL for PB
- Consensus from the maintainer (that's you!) of PB that this is
what we're going to do
I'm happy to write the blog post. How do you feel ending the PB fork maintenance?
Thanks, I'd appreciate if you wrote the blog post.
Will do!
Thanks!
If I were to decide, then I would wanna end PureBrowser fork *now* before next release expected in few weeks, and expected to reintroduce Mozilla- and Google-promoting stuff currently ripped out.
Agreed. This seems like good timing.
Good.
I then recommend to prioritize that blog post, because what I hoped would be a few more weeks ended yesterday: https://lists.debian.org/debian-security-announce/2019/msg00201.html
The gist of it is "...could potentially result in the execution of arbitrary code, information disclosure, cross-site scripting or denial of service" - i.e. scary shit!
I recommend these actions:
1. Include firefox-esr from Debian into both amber and byzantium 2. Change germinate packages to include epiphany and not purebrowser 3. Drop purebrowser from both amber and byzantium 4. Tell users to *immediately* remove purebrowser from their systems, replacing instead with either epiphany or firefox-esr. 5. suggest users moving to firefox-esr to migrate by once running "firefox-esr --migrate" from command-line
Step 5 probably requires Mladen or João playing around with it to confirm it is the best way and maybe put up a guiding web page.
Step 4 depends on step 1, and step 3 probably depends on step 2.
- Jonas
-
Chris Lamb -
François Téchené -
Guido Günther -
Jeremiah C. Foster -
Jonas Smedegaard -
Matthias Klumpp