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.

(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 believe Tor Browser (previously named Tor Browser Bundle a.k.k. TBB) itself was never packaged for Debian, nor released with PureOS.

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?

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

A bit of some history...

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...

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.

This covers several issues, making it difficult to track.

Such change(s) would be encouraging those resources.

Only Matthias has access to automation tools, I believe.

Sorry, above was inaccurate: I _do_ expect FSF to tolerate _FSF_ hosts as "middle-ground" but not e.g. "extensions.gnome.org".

No, "middle-ground" is some other option - possibly one of these:

@todd It seems to me that your question at 11:52 was ambiguous: I guess you intended to ask about _default_ behaviour, and to me it is more likely that Matthias answered only about _ability_ - i.e. that Software center sends requests outside of pureos.net if told to do so. Therefore I disagree that @james.rufer's test is counter to @mak's answer.

Seems to me those fields are simply not provided, and Evince (which it seems you use to parse and inspect the files) wrongly show a bogus timestamp when none is proviced.

The tool nethogs is available in PureOS in the package nethogs. I.e. the tool is "included in most Linux distributions" as was quoted in that forum thread you are linking to.

Reassigning to Matthias, our expert on AppStream (including what and how much PureOS has derived from Debian in that area).

Sorry, I have no special expertise on this issue :-(

evtest output of first pressing backslash/pipe key (lower left corner) and then hash/tilde key (just left of return), with pristine udev:

Event: time 1536705976.250768, type 4 (EV_MSC), code 4 (MSC_SCAN), value 56
Event: time 1536705976.250768, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
Event: time 1536705976.250768, -------------- SYN_REPORT ------------
'Event: time 1536705976.367113, type 4 (EV_MSC), code 4 (MSC_SCAN), value 56
Event: time 1536705976.367113, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
Event: time 1536705976.367113, -------------- SYN_REPORT ------------
Event: time 1536705984.751884, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2b
Event: time 1536705984.751884, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 1
Event: time 1536705984.751884, -------------- SYN_REPORT ------------
'Event: time 1536705984.868556, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2b
Event: time 1536705984.868556, type 1 (EV_KEY), code 43 (KEY_BACKSLASH), value 0
Event: time 1536705984.868556, -------------- SYN_REPORT ------------

The full contents of /sys/class/dmi/id/modalias (usable for udev matching):

dmi:bvncoreboot:bvr4.6-a86d1b-Purism-4:bd06/29/2017:svnPurism:pnLibrem13v2:pvr2.0:rvnPurism:rnLibrem13v2:rvr2.0:cvnPurism:ct9:cvr:

dmidecode -s system-product-name provides same result - if that is what you wanted.

Result of running dmidecode -s baseboard-product-name as root:

Librem 13 v2

Yes, my _problem_ is that pipe key gets mis-interpreted (see T443).

Yes, it is harmless.

Thanks for the feedback.

I seem to recall mentions of filesize related to this: How big were the files you tried but failed to upload?

Hi tasty,

This package - when redistributed in PureOS - does not suggest installing any nonfree packages (only a non-existing package).

I use a Librem 13 v2 UK (see T443).

Ah, the version in the screenshot indicates that it is the Debian package which gets installed.

Password Safe as shipped upstream contains code which has been removed from Debian redistribution due to its licensing.

Hi tronkel,

Speficially Matthias has shared some info here: https://tracker.pureos.net/T99#10198

yes please.

Seems Gimp 2.10 defaults to single window mode, and our fork can be dropped.

Sorry, I don't follow.

yagf does not fallback-depend on a non-free package, only a non-existent one.

hashcat does not fallback-depend on a non-free package, only a non-existent one.

Ah: Dropping the fork was done long ago in T330.

audex does not suggest a non-free package, only a non-existent one.

p7zip does not suggest a non-free package, only a non-existent one.

xarchiver does not suggest a non-free package, only a non-existent one.

foo2zjs does not suggest a non-free package, only a non-existent one.

engrampa does not suggest a non-free package, only a non-existent one.

doublecmd does not suggest a non-free package, only a non-existent one.

clamav does not suggest a non-free package, only a non-existent one.

When addressed, this issue should be flaged as "invalid" (not "resolved").

q4wine does not suggest a non-free package, only a non-existent one.