Re: Policy consensus on transition when removing initscripts.

[Simon McVittie]

On Mon, 26 Jun 2023 at 15:03:51 +0900, Simon Richter wrote:
> On 6/25/23 23:15, Mark Hindley wrote:
> > The most recent proposal[6] for updating the Policy with a requirement to 
> > use
> > tmpfiles.d(5) states
> 
> >   "Init systems other than ``systemd`` should allow providing the same
> >   functionality as appropriate for each system, for example managing the
> >   directories from the init script shipped by the package."
> 
> The way I see it, we are getting a split between "daemons" and "services",
> and it simply does not make sense to start a "service" directly from an init
> script, because it requires the service orchestrator as its runtime
> environment.

That's certainly not how I understand the difference between a service
and a daemon. The LSB specification refers to the functionality provided
by a LSB init script as a service: this is not a new term introduced
by systemd, and daemons that need some one-time setup before the actual
daemon can be started are not a new concept either.

It's true that a lot of system services are a single daemon (long-running
background process) or a wrapper around a daemon, maybe with some extra
setup/teardown: for example /etc/init.d/dbus has always needed to ensure
that the machine ID exists before it can start dbus-daemon, and various
other init scripts need to create a directory in /run or whatever, owned
by the user ID with which they are going to start the actual daemon.
In systemd jargon, the init script is a "forking" service (it forks in
order to run the daemon process in the background, or instructs the
daemon process to use the double-fork pattern).

Other system services have no daemons at all: /etc/init.d/sudo and
/etc/init.d/apparmor do some one-time actions during boot, and then exit,
leaving no processes running (assuming they're working correctly). In
systemd jargon they're "oneshot" services.

A somewhat rarer category of system services involves a top-level init
script or systemd unit that results in multiple daemons being started,
for example /etc/init.d/postfix.

> "If it is present, it also needs to work." sounds like a reasonable
> statement though.

I'm fairly sure that's the intention here.

The typical case where a daemon has a functional dependency on
tmpfiles.d(5) is that the daemon needs some state directories, either on
disk (typically /var/lib) or in RAM (typically /run), to be set up as
root and chown'd to the appropriate user ID before it can do its work.
For example /usr/sbin/foo might run as user ID _foo and require /run/foo
and/or /var/lib/foo to be 0750 _foo:_foo.

Historically a lot of daemons have required being started as root and
then dropped privileges internally, allowing the daemon to set up those
directories while it is still root. However, not all daemon maintainers
will want their daemon implementation to be responsible for doing that:
when touching a non-root-owned directory as root, it's necessary to be
careful to avoid time-of-check/time-of-use attacks (perhaps involving
symlinks or hard links) that could allow a local attacker to trick the
daemon into changing the ownership or permissions of the wrong file.

Not wanting to drop privileges internally at all is also a design choice
for the daemon, and a valid one IMO: as well as the security impact of
any bugs that might exist in the privilege-dropping code, if a process
started as root and dropped privileges to some other uid, that permanently
restricts its ability to read information out of its own /proc, which is
not always desirable. If the daemon starts up unprivileged, then it can
read its own /proc in the usual way, but obviously it can't create a new
subdirectory of /run or /var/lib itself, so someone else needs to do that.

If a daemon needs its state directories set up in advance like that,
and if someone provides an init script, I hope it's uncontroversial
to say that the init script needs to take responsibility for creating
those state directories, either directly or by delegating it to a
dependency. That's equally true regardless of whether the init script
is provided by the same package as the daemon, or by some other package
like orphan-sysvinit-scripts, or by a local sysadmin.

One way to implement pre-creation of state directories is to use
the declarative tmpfiles.d(5) files. On systemd systems, the package
providing the service can rely on systemd to process those files. On
non-systemd-booted systems, one option is to run on the systemd-tmpfiles
executable (from the systemd-standalone-tmpfiles or systemd package)
during boot and during postinst to achieve the same thing. Another
option is to use a reimplementation of the tmpfiles.d(5) interface; a
third option is to open-code the directory creation in the init script
with some appropriate `mkdir -p`, `chmod` and `chown`, or `install -d`.

Looking at reimplementations of tmpfiles.d(5), OpenRC's opentmpfiles
exists as an upstream project, but was removed from Debian, and my
understanding is that

Re: MBF: packages shipping init scripts without corresponding systemd units

[Luca Boccassi]

On Mon, 26 Jun 2023 at 05:21, Paul Wise  wrote:
>
> On Sun, 2023-06-25 at 22:31 +0100, Luca Boccassi wrote:
>
> > Now the generator is also on the way to be deprecated and removed.
> ...
> > Therefore I filed a bug against all affected packages ...
>
> Will the generator be available separately for people who have packages
> not in Debian that still only have init scripts, or for people who have
> local init scripts installed manually or with config management tools?

It will not, it's going to be removed upstream and hence from
src:systemd. Exact date/version is not planned yet, but it will be
before Trixie's dev cycle ends. It will be written down in the release
notes when the time comes.

Kind regards,
LUca Boccassi

Bug#1039468: ITP: node-vm2 -- Advanced vm/sandbox for Node.js

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-vm2
  Version : 3.9.19
  Upstream Author : Patrik Simek (https://patriksimek.cz)
* URL : https://github.com/patriksimek/vm2#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Advanced vm/sandbox for Node.js

vm2 is a sandbox that can run untrusted code with
whitelisted Node's built-in modules. Securely!

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039471: ITP: golang-github-azuread-microsoft-authentication-library-for-go -- allows you to sign in users or apps with Microsoft identities (Azure AD and Microsoft Accounts) and obtain tokens to

[M Hickford]

Package: wnpp
Severity: wishlist
Owner: M Hickford 
X-Debbugs-Cc: debian-devel@lists.debian.org, mirth.hickf...@gmail.com

* Package name: 
golang-github-azuread-microsoft-authentication-library-for-go
  Version : 1.0.0
* URL : 
https://github.com/AzureAD/microsoft-authentication-library-for-go
* License : MIT
  Programming Lang: Go
  Description : allows you to sign in users or apps with Microsoft 
identities (Azure AD and Microsoft Accounts) and obtain tokens to call 
Microsoft APIs such as Microsoft Graph or your own APIs registered with the 
Microsoft identity platform

Bug#1039473: ITP: node-degenerator -- Compiles sync functions into async generator functions

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-degenerator
  Version : 3.0.2
  Upstream Author : Nathan Rajlich  (http://n8.io/)
* URL : https://github.com/TooTallNate/node-degenerator#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Compiles sync functions into async generator functions

This module takes a String to one or more synchronous JavaScript
functions, and returns a new String that with those JS functions
transpiled into async functions.

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1039476: ITP: node-pac-resolver -- Generates an asynchronous resolver function from a PAC file

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-pac-resolver
  Version : 5.0.1
  Upstream Author : Nathan Rajlich  (http://n8.io/)
* URL : https://github.com/TooTallNate/node-pac-resolver#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Generates an asynchronous resolver function from a 
PAC file


This module accepts a JavaScript String of code, which is meant to be a
PAC proxy file, and returns a generated asynchronous FindProxyForURL()
function.

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: MBF: packages shipping init scripts without corresponding systemd units

[Wouter Verhelst]

On Sun, Jun 25, 2023 at 10:31:35PM +0100, Luca Boccassi wrote:
> On Sun, 25 Jun 2023 at 22:29, Luca Boccassi  wrote:
> >
> > Hi,
> >
> > According to Lintian there are 314 packages shipping init scripts
> > without a corresponding systemd unit:
> >
> > https://lintian.debian.org/tags/missing-systemd-service-for-init.d-script
> >
> > They currently work because there is still a transitional unit
> > generator that creates a unit on-the-fly on boot. This was always
> > intended as a temporary stop-gap, and is technically vastly inferior to
> > a native unit, as for example it cannot tell the difference between a
> > one-shot and a long-running service, and cannot enable any hardening or
> > sandboxing options.
> >
> > Now the generator is also on the way to be deprecated and removed. It's
> > been there for a decade, which is enough time to complete the
> > transition, and will likely be removed before Trixie ships.
> >
> > Therefore I filed a bug against all affected packages, provided a patch
> > for policy:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039102
> >
> > and a patch for Lintian to bump the severity from warning to error:
> >
> > https://salsa.debian.org/lintian/lintian/-/merge_requests/407
> >
> > It's possible that there will be a good chunk of false positives, as
> > often new units added don't have a name that matches exactly the old
> > init script name, in which case it's fine to add an override and close
> > the bug.
> 
> It would probably make things easier if I typed the destination
> address correctly.

It's generally expected that you discuss MBFs on this list *before*
actually performing the MBF, so that other options can be discussed, but
meh, whatever.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Policy consensus on transition when removing initscripts.

[Ansgar]

On Sun, 2023-06-25 at 11:15 -0700, Russ Allbery wrote:
> Bastian Blank  writes:
> > Sorry no.  Please add a conversion layer that adopts service and
> > maybe other systemd units to initrc if you care about it.  This is
> > what systemd does to adopt existing init scripts, so you can do the
> > opposite.
> 
> I don't think it's useful to tell people who are working on sysvinit
> support how best to do that work.  We decided to not require support
> in packages and put the maintenance burden on the sysvinit
> maintainers.  It feels rude to me to do that and then try to second-
> guess how they choose to do that.

I think sysvinit maintainers looked at such ideas in the past, but
weren't capable to get it to work. That might be a blocker for such
approaches. There was also a GSoC project in 2012 and some other work.

> [...] we should respect it.

But not necessarily much more than the community the thread starter
works with shows towards others.

> > And it can detect easily if no init script exists for a given unit,
> > so no coordination necessary.
> 
> Replaces and Conflicts are required at the very least so that
> upgrades work properly, and I don't see any reason why we shouldn't
> provide instructions to package maintainers to do that smoothly,
> rather than having the init script disappear and then reappear and
> break users who are using unstable.  It's not that difficult to slow
> down a little bit and follow a process.

Neither orphan-sysvinit-scripts now! nor the packages it ships legacy
startup scripts for seem to have Replaces or Conflicts though?

I also don't think we should put anything here on the critical path:
that lead to problems with, for example, systemd-shim which was
promised to get maintained and timely updated...

Less prone to errors than a manual process might be to watch
automatically where legacy startup scripts disappear anyway; it's not
that complicated to do. People tend to forget things.

Ansgar

Re: Policy consensus on transition when removing initscripts.

[Scott Kitterman]

On Monday, June 26, 2023 12:45:11 PM EDT Ansgar wrote:
> On Sun, 2023-06-25 at 11:15 -0700, Russ Allbery wrote:
> > Bastian Blank  writes:
> > > Sorry no.  Please add a conversion layer that adopts service and
> > > maybe other systemd units to initrc if you care about it.  This is
> > > what systemd does to adopt existing init scripts, so you can do the
> > > opposite.
> > 
> > I don't think it's useful to tell people who are working on sysvinit
> > support how best to do that work.  We decided to not require support
> > in packages and put the maintenance burden on the sysvinit
> > maintainers.  It feels rude to me to do that and then try to second-
> > guess how they choose to do that.
> 
> I think sysvinit maintainers looked at such ideas in the past, but
> weren't capable to get it to work. That might be a blocker for such
> approaches. There was also a GSoC project in 2012 and some other work.
> 
> > [...] we should respect it.
> 
> But not necessarily much more than the community the thread starter
> works with shows towards others.
> 
> > > And it can detect easily if no init script exists for a given unit,
> > > so no coordination necessary.
> > 
> > Replaces and Conflicts are required at the very least so that
> > upgrades work properly, and I don't see any reason why we shouldn't
> > provide instructions to package maintainers to do that smoothly,
> > rather than having the init script disappear and then reappear and
> > break users who are using unstable.  It's not that difficult to slow
> > down a little bit and follow a process.
> 
> Neither orphan-sysvinit-scripts now! nor the packages it ships legacy
> startup scripts for seem to have Replaces or Conflicts though?
> 
> I also don't think we should put anything here on the critical path:
> that lead to problems with, for example, systemd-shim which was
> promised to get maintained and timely updated...
> 
> Less prone to errors than a manual process might be to watch
> automatically where legacy startup scripts disappear anyway; it's not
> that complicated to do. People tend to forget things.

That sounds reasonable.  It might be sufficient for the policy discussion to 
say 
that maintainers who drop sysv init scripts should file a bug against orphan-
sysvinit-scripts with the final version of the provided init attached and which 
lists the lowest version that won't include it (so that orphan-sysvinit-
scripts can Replaces << that version).

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: MBF: packages shipping init scripts without corresponding systemd units

[Scott Kitterman]

On Monday, June 26, 2023 11:52:05 AM EDT Wouter Verhelst wrote:
> On Sun, Jun 25, 2023 at 10:31:35PM +0100, Luca Boccassi wrote:
> > On Sun, 25 Jun 2023 at 22:29, Luca Boccassi  wrote:
> > > Hi,
> > > 
> > > According to Lintian there are 314 packages shipping init scripts
> > > without a corresponding systemd unit:
> > > 
> > > https://lintian.debian.org/tags/missing-systemd-service-for-init.d-scrip
> > > t
> > > 
> > > They currently work because there is still a transitional unit
> > > generator that creates a unit on-the-fly on boot. This was always
> > > intended as a temporary stop-gap, and is technically vastly inferior to
> > > a native unit, as for example it cannot tell the difference between a
> > > one-shot and a long-running service, and cannot enable any hardening or
> > > sandboxing options.
> > > 
> > > Now the generator is also on the way to be deprecated and removed. It's
> > > been there for a decade, which is enough time to complete the
> > > transition, and will likely be removed before Trixie ships.
> > > 
> > > Therefore I filed a bug against all affected packages, provided a patch
> > > for policy:
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039102
> > > 
> > > and a patch for Lintian to bump the severity from warning to error:
> > > 
> > > https://salsa.debian.org/lintian/lintian/-/merge_requests/407
> > > 
> > > It's possible that there will be a good chunk of false positives, as
> > > often new units added don't have a name that matches exactly the old
> > > init script name, in which case it's fine to add an override and close
> > > the bug.
> > 
> > It would probably make things easier if I typed the destination
> > address correctly.
> 
> It's generally expected that you discuss MBFs on this list *before*
> actually performing the MBF, so that other options can be discussed, but
> meh, whatever.

And also so someone can point out your list of affected packages contains 
packages that only exist in oldstable so you can revise you list before 
submitting the bugs.

Scott K


signature.asc
Description: This is a digitally signed message part.

Re: Policy consensus on transition when removing initscripts.

[Bastian Blank]

On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote:
> > Less prone to errors than a manual process might be to watch
> > automatically where legacy startup scripts disappear anyway; it's not
> > that complicated to do. People tend to forget things.
> 
> That sounds reasonable.  It might be sufficient for the policy discussion to 
> say 
> that maintainers who drop sysv init scripts should file a bug against orphan-
> sysvinit-scripts with the final version of the provided init attached and 
> which 
> lists the lowest version that won't include it (so that orphan-sysvinit-
> scripts can Replaces << that version).

Automatically is clearly not the same as "file a bug".  It is not a
useful way to ask hundreds of people to do things if you can do it on
your own.

Bastian

-- 
Military secrets are the most fleeting of all.
-- Spock, "The Enterprise Incident", stardate 5027.4

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Olaf Titz]

> > Oh, wait!  No, I'm wrong, CNFS actually does something smart and encodes
> > the header in ASCII when writing it to disk.
> >
> > Okay, phew, this isn't going to be nearly as bad as I had thought.
>
> Good news. It would be great if you could add relevant info to the wiki page:
> https://wiki.debian.org/ReleaseGoals/64bit-time#Known_Issues

That page now says
< The CNFS storage format does not have problems with its disk format,
< but the less-used timecaf storage format might (yet to be confirmed).

Yes, timecaf does have a problem, two actually.

1. The CF file header contains a field time_t LastCleaned. Changing
sizeof(time_t) will change sizeof(CAFHEADER) and make existing CF file
unreadable with newly compiled code.

AFAICT that field is only written once and never read, so it could be
patched out, but that requires some care.

2. The CF files use file names like timecaf-nn/bb/aacc.CF where nn is
the storage class and aabbccxx the time of arrival, changing the file
name in 256-second intervals. The code using %02x format strings to
determine the file name, and everything else checking them for
validity, will have to be changed appropriately.

Olaf

Re: Policy consensus on transition when removing initscripts.

[Russ Allbery]

Bastian Blank  writes:
> On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote:

>>> Less prone to errors than a manual process might be to watch
>>> automatically where legacy startup scripts disappear anyway; it's not
>>> that complicated to do. People tend to forget things.

>> That sounds reasonable.  It might be sufficient for the policy
>> discussion to say that maintainers who drop sysv init scripts should
>> file a bug against orphan- sysvinit-scripts with the final version of
>> the provided init attached and which lists the lowest version that
>> won't include it (so that orphan-sysvinit- scripts can Replaces << that
>> version).

> Automatically is clearly not the same as "file a bug".  It is not a
> useful way to ask hundreds of people to do things if you can do it on
> your own.

I think the open question is whether we're happy to just break init
scripts in unstable, since that migration path means there will always be
a window where a fully-upgraded unstable system has no init script for a
package that previously had one and in the future will have one again.

This feels like exactly the kind of problem that normally Debian goes to
some lengths to avoid creating, but it sounds like several commenters here
don't think the effort is worth it?

If we don't want to break init scripts in unstable, then the package
maintainer should wait for the upload of orphan-sysvinit-scripts that
contains the script before uploading the version that drops it.

I thought for a bit that some dependency other than Replaces/Conflicts
would be appropriate, but the more I think about it, the more I'm not sure
there is.  (Well, Enhances in orphan-sysvinit-scripts, but I'm not sure
that changes apt behavior in any way.)  Presumably the sysvinit init
system package should depend on orphan-sysvinit-scripts, so the
Replaces/Conflicts should then force the right upgrade to happen.

-- 
Russ Allbery (r...@debian.org)  

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Aurelien Jarno]

On 2023-06-09 16:39, Thorsten Glaser wrote:
> In particular I would, at the same time, like the baseline lowered
> to i586 again. It was raised mostly for multimedia stuff, and it’s
> now justifyable to ask people to use amd64 or armhf or something for
> that.

This is plainly wrong. The current baseline of the i386 architecture
does NOT include any multimedia extension, and certainly not MMX nor
SSE.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Bug#1039507: ITP: node-pac-proxy-agent -- PAC file proxy `http.Agent` implementation for HTTP and HTTPS

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-pac-proxy-agent
  Version : 5.0.0
  Upstream Author : Nathan Rajlich  (http://n8.io/)
* URL : https://github.com/TooTallNate/node-pac-proxy-agent
* License : Expat
  Programming Lang: JavaScript
  Description : PAC file proxy `http.Agent` implementation for HTTP 
and HTTPS


This module provides an http.Agent implementation that retreives the
specified PAC proxy file and uses it to resolve which HTTP, HTTPS, or SOCKS
proxy, or if a direct connection should be used to connect to the HTTP
endpoint. It is designed to be be used with the built-in http and https
modules.

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Policy consensus on transition when removing initscripts.

[Scott Kitterman]

On Monday, June 26, 2023 2:02:24 PM EDT Bastian Blank wrote:
> On Mon, Jun 26, 2023 at 01:22:38PM -0400, Scott Kitterman wrote:
> > > Less prone to errors than a manual process might be to watch
> > > automatically where legacy startup scripts disappear anyway; it's not
> > > that complicated to do. People tend to forget things.
> > 
> > That sounds reasonable.  It might be sufficient for the policy discussion
> > to say that maintainers who drop sysv init scripts should file a bug
> > against orphan- sysvinit-scripts with the final version of the provided
> > init attached and which lists the lowest version that won't include it
> > (so that orphan-sysvinit- scripts can Replaces << that version).
> 
> Automatically is clearly not the same as "file a bug".  It is not a
> useful way to ask hundreds of people to do things if you can do it on
> your own.

Are hundreds of people dropping init scripts?  I'm curious how you measure 
that?

Scott K

signature.asc
Description: This is a digitally signed message part.

Bug#1039519: ITP: golang-maunium-go-mauflag -- Extendable argument parser for Golang

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 

* Package name: golang-maunium-go-mauflag
  Version : 1.0.0-1
  Upstream Author : 2016 Maunium
* URL : https://github.com/tulir/mauflag.git
* License : GPL-3
  Programming Lang: Go
  Description : Extendable argument parser for Golang
 Mauflag is an extendable argument parser for golang that mostly
 follows GNU Program Argument Syntax Conventions.
 .
 This is a transitive dep of gomuks.

Bug#1039523: ITP: x2gokdrive -- KDrive graphical server backend for X2Go Server

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: x2gokdrive
  Version : 0.0.0.1
  Upstream Contact: Oleksandr Shneyder 
* URL : https://code.x2go.org/gitweb?p=x2gokdrive.git;a=summary
* License : GPL-2+
  Programming Lang: C
  Description : KDrive graphical server backend for X2Go Server

 X2Go is a server based computing environment with
- session resuming
- low bandwidth support
- session brokerage support
- client-side mass storage mounting support
- client-side printing support
- audio support
- authentication by smartcard and USB stick
 .
 This package is built from the X.org xserver module. X2Go KDrive is a
 KDrive-based Xserver for X2Go. It provides support for running modern
 desktop environments like GNOME, KDE Plasma, Cinnamon, etc. in X2Go
 Sessions.
 .
 The X2Go KDrive graphical backend is not suitable for low bandwidth WAN
 connections between X2Go Client and X2Go Server. It is supposed for X2Go
 being used on the local area network.
 .
 More information about X.Org can be found at:
 https://www.x.org>
 .
 More information about X2Go can be found at:
 https://wiki.x2go.org>
 .
 This package will be maintained under the umbrella of the Debian Remote
 Packaging Team.

Bug#1039524: ITP: node-proxy-agent -- Maps proxy protocols to http.Agent implementations

[Israel Galadima]

Package: wnpp
Severity: wishlist
Owner: Israel Galadima 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name    : node-proxy-agent
  Version : 5.0.0
  Upstream Author : Nathan Rajlich  
(http://n8.io/)

* URL : https://github.com/TooTallNate/node-proxy-agent
* License : Expat
  Programming Lang: JavaScript
  Description : Maps proxy protocols to http.Agent implementations

This module provides a function that returns proxying http.Agent
instances to use based off of a given proxy URI.

This package is part of my effort to package corepack for Debian.
Package will be maintained by the Debian JavaScript Team.



OpenPGP_0x3679ECB87B7CEC0C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Policy consensus on transition when removing initscripts.

[nick black]

Simon McVittie left as an exercise for the reader:
> started as root and dropped privileges to some other uid, that permanently
> restricts its ability to read information out of its own /proc, which is
> not always desirable. If the daemon starts up unprivileged, then it can

i assume by "its own /proc" you mean /proc/getpid()? i don't see
how this is different from any other resource one might need
consider acquiring prior to dropping privileges. if i want to
open a privileged port, i'd better do that before i change my
user (or otherwise yield CAP_NET_BIND_SERVICE).

furthermore, this is only true when procfs is mounted with a
nonzero hidepid, right? all my /proc/PID directories are 0755,
with contents likewise generally world-readable. hidepid=off is
the default according to
https://www.kernel.org/doc/html/latest/filesystems/proc.html.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Re: Policy consensus on transition when removing initscripts.

[Paul Wise]

On Mon, 2023-06-26 at 20:04 -0400, nick black wrote:

> furthermore, this is only true when procfs is mounted with a
> nonzero hidepid, right?

I note that systemd does not support non-zero hidepid, so
procfs hidepid will always be off on systemd based systems:

https://github.com/systemd/systemd/issues/12955

At least until Linux offers a way for systemd to have access
to /proc but other programs to not have access to it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#1039556: ITP: volare -- tiling, tabbed Wayland compositor based on Sway

[Robert Edmonds]

Package: wnpp
Severity: wishlist
Owner: Robert Edmonds 

* Package name: volare
  Version : No releases yet
  Upstream Author : Arnout Engelen
* URL : https://codeberg.org/raboof/volare
* License : MIT
  Programming Lang: C
  Description : tiling, tabbed Wayland compositor based on Sway

 Volare is a tabbed, tiling Wayland compositor based on Sway, with
 modifications to make its window management behavior similar to that of
 the Notion window manager. Many tiling window managers are "dynamic",
 meaning they automatically change the tiling layout as windows appear
 and disappear. Volare's behavior is more static, keeping the user's
 existing tiling layout in place without automatically rearranging the
 tiling layout as application windows are created, moved, or destroyed.

-- 
Robert Edmonds
edmo...@debian.org