Bug#809705: general: let people use non-free software but opt-out of non-open software

On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER wrote: > Discussing infrastructure changes like what you're proposing (which I > have no advice about) should usually be done through our mailing > lists, Which one would be the appropriate list? I thought general would fit,

Bug#809705: general: let people use non-free software but opt-out of non-open software

Hey Niels On Mon, Jan 4, 2016 at 8:45 AM, Niels Thykier <ni...@thykier.net> wrote: > Philippe Cerfon: > Your second item has been brought up before with different > focus/rationale/purpose. At least I remember there being an interest in > splitting "non-free" into &qu

Bug#809705: general: let people use non-free software but opt-out of non-open software

Hey. On Mon, Jan 4, 2016 at 10:13 AM, Bas Wijnen wrote: > debian-project, or hopefully debian-devel. -project for talking about the > idea, -devel for discussing an implementation. Mehdi mentioned below that it would already land on debian-devel. So I'm not sure whether it

Bug#809354: privacy/security enhancements

Package: iceweasel Severity: wishlist Dear maintainer(s). Unfortunately Mozilla puts more and more questionably stuff into Firefox, where things like CDM[0] are only the tip of the iceberg. I've seen that you already override several settings via debian/browser.js.in. Would you please consider

Bug#809705: general: let people use non-free software but opt-out of non-open software

Package: general Severity: wishlist Tags: security Hi. I think Debian has the following two problems (or rather its security conscious users) with respect to software that gets into the system: First, more and more packages install software which sneaks around the package manager (and thus

Bug#809705: general: let people use non-free software but opt-out of non-open software

Stefano Zacchiroli wrote: >Another one that is worth mentioning here --- which I discussed in > the > context of non-free.org with Dafydd Harries and others --- is > introducing a debtags facet to capture the reason why a package is in > non-free. I'd still say that solving that via debtags isn't

Bug#809705: general: let people use non-free software but opt-out of non-open software

On Wed, Jan 6, 2016 at 1:10 PM, Ansgar Burchardt wrote: > Then why should one have "non-open" at all? The argument was that this > somehow brings some sort of "security" by being able to audit things > (though the license may probably still forbid you from doing so or >

Bug#824520: RFP: subsurface -- scuba diving logbook

Package: wnpp Severity: wishlist * Package name: subsurface Version : 4.5.6 Upstream Author : Dirk Hohndel * URL : https://subsurface-divelog.org/ * License : GPL Programming Lang: C++ Description : scuba diving logbook Apparently,

Bug#824520: Just don't

Hey Salvo. Well I've seen that discussion and upstream seems to be pretty hostile against distributions (and apparently security as well). :-( On the other hand, Debian now unfortunately lacks subsurface packages (while other distros have them, or at least more well integrating repos). So

Bug#987428: libwebkit2gtk-4.0-37: only recommned xdg-desktop-portal-gtk

Package: libwebkit2gtk-4.0-37 Version: 2.30.6-1 Severity: wishlist Hey. Would it be possible to only recommend xdg-desktop-portal-gtk instead of depending on it? It seems to be only required for stuff like Flatpak and Snap running inside a bupplewrap pseudo-sandbox. So everyone else not using

Bug#1003032: debootstrap: harden signature checking

Package: debootstrap Version: 1.0.126+nmu1 Severity: normal Tags: security Hey there. As far as I understood it, debootstrap defaults neither to --no-check-gpg nor to --force-check-gpg, but instead, if a keyring is speicified for some distribution and if that file is available, it uses (and

Bug#1003033: cowdancer: harden package verification

Source: cowdancer Version: 0.89 Severity: wishlist Tags: security Hey. I was looking a bit through the code of cowbuilder and qemubuilder. E.g. for qemubuilder, the manpage already says: "The possible configuration options are as follows. Others are ignored." Altough, it seemed in the code

Bug#824520: RFP: subsurface -- scuba diving logbook

Hey David. I've just seen your replace from 4 years ago now[0]. O;-) Are you still working on this? Would love to see subsurface coming back to Debian, cause right now I think there is not divecomputer/log software in it at all. It seems libdivecomputer has also been gone from Debian :-( ;ay

Bug#824520: RFP: subsurface -- scuba diving logbook

btw... I've just seen there's: http://ppa.launchpad.net/subsurface/subsurface/ubuntu (including packaging for all the deps) So maybe, it could be much simpler to get this back into Debian, by simply basing the Debian packaging on Ubuntu's.

Bug#824520: RFP: subsurface -- scuba diving logbook

On Sun, May 22, 2022 at 2:09 PM David Bremner wrote: > To be honest, I doubt that helps, since the hard part is not just making > packages (my repo on salsa already does that), but making them in a way > acceptable to debian policy, which is unlikely to be a priority for a > PPA. Were there any

Bug#824520: RFP: subsurface -- scuba diving logbook

On Sun, May 22, 2022 at 10:45 PM Salvo Tomaselli wrote: > My advice is to forget this. Upstream is really uncooperative and > Torvalds went to conferences to talk about this (conveniently > forgetting to mention he was depending an unstable library whose > author said "Don't use this yet") Well

Bug#1012547: linux: disable user namespaces per default

On Thu, Jun 16, 2022 at 6:19 PM Philippe Cerfon wrote: > Well I guess the 6 or so root security holes, and counting And here we go already, faster than even I'd have expected: Say welcome to CVE-2022-32250, the next root security hole which would apparently have been mitigated if Debian w

Bug#1012547: linux: disable user namespaces per default

Source: linux Version: 5.17.11-1 Severity: normal Tags: security Hi. Some time ago, Debian decided to enable user namespaces per default. Since then we've had numerous security holes which would have been prevented when user namespaces were disabled. I vaguely recall at least around 6-7 such

Bug#1012547: linux: disable user namespaces per default

On Mon, Jun 13, 2022 at 4:56 PM Ben Hutchings wrote: > This is wrong. Well quite apparently not. > On the desktop, browsers and Flatpak rely on user > namespaces for sandboxing (with an alternative being to install more > programs setuid-root). At least firefox doesn't seem to need it, neither

Bug#1010704: chromium: please provide courgette-tool as a package

Source: chromium Version: 101.0.4951.54-1 Severity: wishlist Dear maintainer. The Google Chromium source tree contains the tool courgette, which makes binary deltas (allegedly much better than bsdiff, upon which it is based). Chrome uses it for updates, but it seems that there's also a little

Bug#1012547: linux: disable user namespaces per default

Here we go, another one, it seems: CVE-2022-2588 (https://seclists.org/oss-sec/2022/q3/115) Seems I'm not the only one who's quite concerned about the ongoing security impact of user namspaces, as the recent/current discussion about some LSM patches for 6.1 shows:

Bug#1012547: linux: disable user namespaces per default

Apparently it's already Christmas: The next two holes that likely allow privilege escalation and that would have been mitigated by unprivileged user namespaces being disabled: CVE-2022-1015, CVE-2022-1016 Cheers, Phiippe

Bug#1026839: systemd: kills --user services after logging out

Hey Michael. So that means KillUserProcesses= affects only non-service user processes? It's a little bit hard to read that out of it's description in logind.conf(5). Would it help it that simply says something that this option doesn't affect --user services? Thanks, Philippe

Bug#1026839: systemd: kills --user services after logging out

Package: systemd Version: 252.3-2 Severity: normal Hey. What I do is about the following: I log on via SSH to some node, and a "special" remote command starts a VNC server as systemd --user service and upon certain signals it stops it, while on HUP it just exits. The idea is that in the HUP

Bug#1024866: vlock: special passphrase(s) that execute a kill-command

Package: vlock Version: 2.2.2-11 Severity: wishlist Hey. It seems vlock has no longer any upstream? It would be nice, when one could configure a special passphrase (or maybe even more) which, when entered, doesn't unlock the terminal, but instead executes a configurable command (depending on

Bug#1040661: RFP: rust-palette -- Convert and manage colors with a focus on correctness, flexibility and ease of use.

Package: wnpp X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net Severity: wishlist * Package name: rust-palette Version : 0.7.2 Upstream Contact: https://crates.io/users/Ogeon * URL : https://github.com/Ogeon/palette * License : APACHE, MIT

Bug#1040662: RFP: rust-smol-str -- small-string optimized string type with O(1) clone

Package: wnpp X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net Severity: wishlist * Package name: rust-smol-str Version : 0.2.0 Upstream Contact: Aleksey Kladov * URL : https://github.com/rust-analyzer/smol_str * License : APACHE, MIT Programming