@kyle.rankin @mladen.pejakovic

so far we don't have anyone in-house who is able to re-create this specific problem but clearly you are getting some kind of support request that motivated you to file this ticket.

Oh, neat!
Package synced with unstable.
2018-10-25 14:36:49 - INFO: Imported 'xscreensaver_5.40-1.dsc' to 'landing/main'.

more info at https://bugs.debian.org/876087 and T235.

I want TB to be packaged by PureOS and installed by default on PureOS unless there is some Free Software licensing issue that would prevent this (I don't believe there is).

@sean.obrien While that "Flatkill" (what a dumb name...) makes excellently valid points, there's nothing that is a fundamental flaw in Flatpak's design that won't be resolved with better maintenance and more development time. However, that's something that still needs to happen, and when creating something new, you need to start somewhere ;-)
But anyway, it's better to have this discussion at a different place, to not make the discussion on this (syncing) issue overly hard to follow.

@guido

For our CI we can (and will auto upload to purple/laboratory for some stuff but I'm really talking about things we want from other Debian suites not necessarily maintained by us.

This was fixed on 2018-10-15 with Thunar update 1.8.2-1. Debian testing package changelog ( http://metadata.ftp-master.debian.org/changelogs//main/t/thunar/thunar_1.8.2-1_changelog ) reads in part:

In T594#11055, @guido wrote:

@sean.obrien (this might become a bit off topic): the flatpak side needs more work for the 3rd party apps.

@sean.obrien (this might become a bit off topic): the flatpak side needs more work for the 3rd party apps.

@guido got it, thanks! The further we can think down the road the better, so if I can be of any help let me know. I'm not yet sure what else might be necessary / desired by devs for mobile app development.

We have purple and laboratory in PureOS and the CI repos for phone development.

Anything we can do to make developing apps for the Librem phone smoother is really important. Does it make sense at this point to author a strategy / procedures for packages like this? Maybe a separate repo for unstable packages that we want to make available on PureOS as quickly as possible to encourage Librem phone development? I'm still getting my feet wet, so perhaps some of this is worked out already.

Sure let's discuss more (edit: in another medium). I intend to solve the root problem identified by @thegoat above:

Please see the GNOME case above, this is really not tied to our CI.

You have me confused now. I thought the whole transitioning between landing -> and green is there to detect these inconsistencies?

You have me confused now. I thought the whole transitioning between landing -> and green is there to detect these inconsistencies?
Also I'd be syncing for me does not imply syncing binaries. Rebuilding the ones not synced from testing would be a great first step in rebuilding everything.

I believe I understand you opinion on this. I then disagree, however.

A thought - If the issue is PureOS/Purism governance, then maybe we just take the TB downloader package from Debian contrib and start maintaining it in-house, making sure we have someone tracking changes in upstream TB very closely so we don't lag behind, and building a good relationship with Tor Project where we give them a heads up that we're doing this. We should also build a relationship with the Debian package managers for that downloader script... it's quite possible they're happy for us to be the maintainers for Debian contrib as well. But maybe not.

The problem here is that we sync binaries and are based on Debian testing. We can't just selectively sync some stuff from unstable, because unstable packages might be built against other things that are only available in unstable (e.g. newer versions of libraries with soname bump). So doing that properly would always be a manual action.
I could change the code and implement something that allows syncing some packages only by source, but that will take a bit of time and might likewise cause trouble with packages synced from testing that would have to be rebuilt against the source-sync from unstable. That's why I did not implement this feature initially, in principle, to avoid having scenarios where the automation breaks things or causes unexpected sideeffects.

In T347#11041, @jonas.smedegaard wrote:

Is it in your opinion more important to fix immediately (i.e. no time to wait for PureOS, we must hand over the keys to the castle to upstream) bugs in Tor Browser, or do you find it equally important that we (as they become available) enable mechanisms for the Linux developers and GNOME developers and any other upstreams to address 0-days in their code?

Uploading to once place is more comfortable than to two ;)

Is it in your opinion more important to fix immediately (i.e. no time to wait for PureOS, we must hand over the keys to the castle to upstream) bugs in Tor Browser, or do you find it equally important that we (as they become available) enable mechanisms for the Linux developers and GNOME developers and any other upstreams to address 0-days in their code?

Agreed, torbrowser-launcher has been and still is in debian (just not main).
However, since that package bypasses APT, Debian has effectively passed on the maintenance of Tor Browser itself (not the bypassing script, but that it less relevant) to upstream, so how responsive the Debian security team has been regarding torbrowser-lanucher is irrelevant to 0-days of Tor Browser itself.

We don't automatically sync stuff with Debian unstable, and if I do a one-time sync the package will be out of date again rather soon.
So, maybe just uploading the latest version of libhandy to PureOS directly is a better option for you? It already is in the laboratory/purple suites afterall.

Let me rephrase: The Tor Browser launcher/downloader *has* been packaged for Debian. I believe it has lagged behind in updates, even in my past experience, but I would want more concrete information on that.

(reminder: Feel free to disagree - I don't state universal facts here, just am inconsistent in adding "in my opinion"...)

In-browser mechanisms to bypass APT is severe bugs that should be fixed by patching them away, as is currently done for PureBrowser.

0-day issues with Tor Browser should be handled exactly same as 0-day issues for all parts of PureOS: By PureOS developers issuing a bugfix.

I do not recommend that PureOS bypass Debian and pull directly from upstream - either as PureOS-specific development effort (a package) or by our users (a script like torbrowser-bundle). The amount of work is less but we loose the security tracking and wider use (more eyeballs) from Debian.

I believe Tor Browser (previously named Tor Browser Bundle a.k.k. TBB) itself was never packaged for Debian, nor released with PureOS.

In T347#11031, @jonas.smedegaard wrote:

In my opinion, this issue should be solved by packaging Tor Browser for Debian main.

In my opinion, this issue should be solved by packaging Tor Browser for Debian main.

...but the very issue you are raising here, if I understand you correctly, is that things like Electron apps and Tor Browser are - in your opinion - reasons to relax that "whenever possible" part. Right?

The problem here is very nicely explained, and I agree that a reference document with a high-level design pattern we can refer to is the best solution. Let me know if there's anything I can do to move this along.

Suggestion - can we figure out a workflow with subtasks and/or parent tasks? That way there's no need to look outside of this issue tracker for solutions, and we can sort/clean up current tasks here that may be in the kind of limbo you describe.

What do we need to do to move this forward? We really need to have Tor Browser available in some form. @jonas.smedegaard I know we've had some discussions about software outside of PureOS repo in general. What's your suggested solution for shipping TBB (or do you suggest not shipping it)?

In T596#11020, @jonas.smedegaard wrote:

Others than me in Purism/PureOS are happy about Flatpack - doesn't that provide the needed sidechannel for injecting these popular tools?

Others than me in Purism/PureOS are happy about Flatpack - doesn't that provide the needed sidechannel for injecting these popular tools?

In T596#11018, @jonas.smedegaard wrote:

A bit of some history...
Last fall, soon after I was hired to Purism and my interest in nitpicking and policy making became clear, I was tasked with tracking "Freedom issues" - i.e. make sure PureOS would comply with FSF FSDG.
Instead of simply "obey the gospel of FSF", I tried make sense of their rules and find the logic that make sense to me that PureOS follows - which happens to fit FSF rules but makes sense on its own as well.
The rule I have followed - which FSF does not dictate but in my interpretation fits their concretely written rules - is that PureOS must be responsible towards our users in what we offer them.
My guess is that FSF has peculiarly odd phrases like "Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow" is that they don't trust other organisations (e.g. Debian) to stay on the rght path, but they do want other organisations to trust them (e.g. use their list of Mozilla-compatible addons).

A bit of some history...

Thanks @jonas.smedegaard ! Potentially this is a bad forum for this discussion but I appreciate the title change.

I don't mean to kill the conversation here. Just want to keep separate concrete issues from "meta issues". I will take the liberty of relabeling this one to perhaps better fit what we are discussing here...

I'll add really quickly - if Debian main is still considered problematic, I understand, but I don't think that precludes making some of the Electron-based clients for E2EE messaging available through their repos (though not marked by default).

You're quite right that the GNU FSDG is very clear on this issue:

Regarding what we can and cannot do according to FSF guidelines: Are you asking what the guidelines says, or are you asking how much we can bend the rules before our relations with them snap?

Not sure what you mean by "replicate everything in-house".

To clarify: You do _not_ need to search through and locate previous issues. Nice if you do, but perfectly fine if you don't have time for that. File new issues and leave it to us to correlate and maybe merge with existing ones. :-)

I agree none of what you presented here _is_ T247 - only _related_ to it.

Seems to me that the best course of action is to talk to DuckDuckGo and see what the opportunities are here. We could of course use DuckDuckGo's search without any discussion, but a custom arrangement might be better for both parties.

Understood, I'll think about this and see if it makes sense to comment on these other issues or open new, separate ones. However - T247 doesn't quite fit with the UA issue. The User Agent behavior is identifying PureBrowser in the way that has been decided in past discussions/issues, but Mozilla is detecting PureBrowser as not Firefox. Users who click Tools > Add-ons are given choices that don't work, and diverted down channels that go nowhere. See for example the attached screenshot of what my PureBrowser is currently recommending to me on the "Get Add-ons" screen.

This covers several issues, making it difficult to track.

In T596#10989, @jonas.smedegaard wrote:

Such change(s) would be encouraging those resources.
Since those resources are external to us, we cannot ensure our users that they fit our constraints e.g. regarding software freedoms - and even if they happen to currently align with out constraints we have no way of intervening if that change later on, after our users have installed our system onto their systems.
PureOS is the subset of Debian which is "Free" both by Debian definitions and by Free Software Foundation definitions. Encouraging inclusion of Debian resources would - in the eyes of FSF - be encouraging non-free stuff, and we would loose the endorsement from FSF as being a Free system by their standards.

Such change(s) would be encouraging those resources.

Only Matthias has access to automation tools, I believe.

I had this issue on the OEM version of PureOS 8 Beta 1, Librem 15 v3. I ended up doing a full reinstall of PureOS.

Thanks for the info on exiftool. I installed it and compared its output with pdfinfo, which was already installed as part of the poppler-utils package. There are slight differences (pdfinfo gives the page size), but both just do not report a nonexistent Creation Date or Modify Date. So at least they don't make up a bogus date for either of those.

As of today 2018-10-08, after intervening system updates, this issue persists. In the meantime I had to install an Xubuntu VM in Boxes, and then install Firefox within the VM.

I'm logged in under GNOME (default Wayland), not GNOME on Xorg, and I get this from gnome-logs after Thunar crashes:

As of today's updates (2018-10-08), this issue persists and is still seen with a number of applications: PureBrowser, GNOME Web (Epiphany), Kate, and Okular. It seems to have been fixed for GNOME Files (Nautilus) and Thunar.

I also encountered this issue today trying to install on my desktop with a USB mouse.

https://bugs.debian.org/906609#30 segfault should be fixed...

I'm going to go ahead and make the executive decision of un-assigning myself from this ticket - feel free to assign back if there is a "Next Action" for me of course, but I do not have an obvious step to proceed.

This was fixed a long time ago.
See https://tracker.pureos.net/T559#10667 for some instructions on how to resolve the configuration issue.

This looks like expected behavior to me: The first prompt is for the disk password, while the second one is for root permission to be actually able to mount the device.
However, there might still be an issue here, because apparently the disk is mounted twice, and also a local user should be able to mount disks directly without root permission, so the second authentication request might not be needed (it could be though that the system policy on what the user can do is different for encrypted disks compared to regular volumes).

Terrific. I am glad that worked for you.

Oh and btw. how do you intend to detect tampering anyway? Please don't tell me you need a Librem Key. Purism tries to sell the laptops as secure and not secure-with-additional-hardware, right? Or is the Key now part of the laptop shipment? If not, what is your security goal for a humble users without Librem Key?