Bug#1041747: ITP: golang-github-containers-libtrust -- Primitives for identity and authorization

Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-containers-libtrust Version : 0.0~git20230121.c1716e8-1 Upstream Author : Containers * URL : https://github.com/containers/libtrust * License : Apache-2.0 Programming Lang:

Re: HFS/HFS+ are insecure

On Fri, 2023-07-21 at 18:35 +0100, Matthew Garrett wrote: > On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote: > > > Unless somebody has a better idea then then my plan is to ship in the > > next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist > > directive to preve

Bug#1041733: ITP: rust-linemux -- asynchronous, multiplexed file tailing

Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-linemux Version : 0.3.0 Upstream Contact: Jon Magnuson * URL : https://github.com/jmagnuson/linem

Bug#1041718: ITP: keepassxc-proxy-client -- Library to access a running KeepassXC instance

Package: wnpp Severity: wishlist Owner: Antonio Russo X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: keepassxc-proxy-client Version : 0.1.6 Upstream Contact: Henrik Böving * URL : https://github.com/hargoniX/keepassxc-proxy-client * License : ISC

Bug#1041717: ITP: tailspin -- log file highlighter and a drop-in replacement for tail -f

Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: tailspin Version : 1.0.0 Upstream Contact: Ben Sadeh * URL : https://github.com/bensadeh/tailspin * Lic

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

El 10/07/23 a las 14:52, Helmut Grohne escribió: > On Sun, Jul 09, 2023 at 05:58:07PM +0100, Luca Boccassi wrote: > > On top of that, a minimal installation chroot doesn't need a > > fully-featured dhcp client. As Simon said already, busybox is there > > for any reason for a minimal one. For the re

Re: HFS/HFS+ are insecure

On 2023-07-22 08:54:59 +0100 (+0100), Matthew Garrett wrote: [...] > When is a user going to plug in a USB stick and *not* click that > button? I'm not analysing a filesystem by hand to check whether > it's trustworthy before I want it mounted. There's no reason to > automount when the screen is lo

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine wrote: > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > wrote: > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago

Bug#1041698: ITP: ruby-flores -- Fuzz, randomize, and stress your tests

Package: wnpp Severity: wishlist Owner: Ajayi Olatunji X-Debbugs-CC: debian-devel@lists.debian.org * Package name: ruby-flores Version : 0.0.8 Upstream Author : Jordan Sissel * URL : https://github.com/jordansissel/ruby-flores#readme * License : Apache P

Re: HFS/HFS+ are insecure

On Sat, Jul 22, 2023 at 10:21:47AM +0200, Jonas Smedegaard wrote: > Quoting Matthew Garrett (2023-07-22 09:54:59) > > On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote: > > > Disabling auto-mounting and for manual GUI mounts, requesting users > > > confirm they trust the filesystem they are

Re: HFS/HFS+ are insecure

Quoting Matthew Garrett (2023-07-22 09:54:59) > On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote: > > Disabling auto-mounting and for manual GUI mounts, requesting users > > confirm they trust the filesystem they are mounting would avoid that > > as much as is reasonably possible without e

Re: HFS/HFS+ are insecure

On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote: > That still potentially exposes insecure code to untrusted data, just in > a user context rather than a kernel context. The same goes for uml + > fuse + namespaces, and even guestfs VMs. You can move the data and code > to different conte

Re: HFS/HFS+ are insecure

On Fri, 2023-07-21 at 10:28 +, Bastien Roucariès wrote: > Long term solution will be to push under fuse these filesystem. > This a (short term)/(medium term band aid) solution. That still potentially exposes insecure code to untrusted data, just in a user context rather than a kernel context.