Bug#1053818: ITP: pkcs11-provider -- OpenSSL 3 provider for PKCS11

[Luca Boccassi]

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

* Package name: pkcs11-provider
  Version : 0.2
  Upstream Contact: Red Hat
* URL : https://github.com/latchset/pkcs11-provider
* License : Apache-2.0
  Programming Lang: C
  Description : OpenSSL 3 provider for PKCS11

With this provider for OpenSSL you can use the OpenSSL library
(version 3) and command line tools with any PKCS11 implementation as
backend for the crypto operations.

-- 
Kind regards,
Luca Boccassi


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

Bug#1053817: ITP: python-ping3 -- Python module and command to ping hosts using raw sockets

[Carles Pina i Estany]

Package: wnpp
Severity: wishlist
Owner: Carles Pina i Estany 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: python-ping3
  Version : 4.0.4
  Upstream Contact: kyan001 
* URL : https://github.com/kyan001/ping3
* License : MIT
  Programming Lang: Python
  Description : Python module and command to ping hosts using raw sockets

 Ping3 is a pure Python 3 version of the ICMP ping implementation using
 raw sockets.

 This package installs the library for Python 3 and also the "ping3" command.

-
This is a soft dependency of "simplemonitor" (ITP #1016113).

"Soft" dependency because simplemonitor can operate without it if not
using the monitor "ping" (and, instead, using the monitor "host" which
spawns /usr/bin/ping).

Users using "simplemonitor" in Debian, if "ping3" is not available,
would not be able to share files between a simplemonitor from pypi or
from Debian.

Using python-ping3 in simplemonitor also improve efficiency.

I plan to maintain it isnide the debian-python team.

I am looking for a sponsor.

Re: [RFC] locking down rsyslog.service

[Robert Edmonds]

Michael Biebl wrote:
> While the attempt is to secure the default configuration of rsyslog, I
> do not want to restrict it so much that it becomes unusable.
> If you think, that one of those directives could cause issues with
> commonly used setups, please let me know, so I can adjust the
> configuration.
> 
> Looking forward to your feedback.

Maybe also add `RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX`?

I see the rsyslog package is compiled without capng support:

  --enable-libcap-ng  Enable dropping capabilities to only the necessary
  set [default=no]

With the libcap-ng dependency rsyslog can apparently perform capability
privilege dropping at some point during startup:

https://sources.debian.org/src/rsyslog/8.2308.0-1/tools/rsyslogd.c/#L1584-L1664

I seem to recall that capability dropping requires additional
privileges, though (CAP_SETPCAP?).

Is this code in rsyslog maybe redundant if the process starts up with
the already reduced set of capabilities and that's the rationale for not
building the package with --enable-libcap-ng? I guess if that's the case
then there aren't any capabilities that are needed by rsyslog only
briefly at startup that can be dropped by the daemon itself?

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

Re: Please test apt-listchanges 4.0 in experimental

[Alexandre Detiste]

Le mer. 11 oct. 2023 à 14:54, Jonathan Kamens  a écrit :
> Can you confirm that this occurred with 4.0 rather than 4.1?
I'm a bit messy & forgetful these times.
But you have #1053812 against 4.1 already.

> > Can annotations/mypy testing be considered now "best practices" for
> > Debian native packages ?
>
> Best practice? Sure. Requirement? Not so much.

Of course it's not a requirement;
and it can be done iteratively.


> Regarding apt-listchanges in particular, I have already spent countless hours 
> getting
> ready for this new release, including the addition of a substantial unit-test 
> suite
> where there were no tests before.

I see it, and it's nice work.

> I do not have the bandwidth to add type hints as well,
> and I do not think this should be a blocker to releasing the new version to 
> the public.

This is why I propose to do it.

> I am happy to consider a MR if someone else wants to add typing to the 
> code-base.

There's a first MR pending.

There's another one against python3-debconf with 100% "mypy --strict" coverage.

I just don't  know how to handle the "py.typed" there: it's a flag
file, contents doesn't matter.
It could be a "touch" in debian/rules, I just don't know what is the
prefered way.

Greetings

Re: [RFC] locking down rsyslog.service

[Michael Biebl]

Am 11.10.23 um 13:41 schrieb Michael Biebl:

Am 11.10.23 um 12:54 schrieb Sam Morris:

On 10/10/2023 19:22, Michael Biebl wrote:

I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives


Have you considered NoNewPrivileges=yes?

This is turned in implicitly by some of the other options (e.g,. 
PrivateDevices=yes) but only if running without CAP_SYS_ADMIN, so for 
it to be effective you'd have to set it explicitly.




Thanks. Will add it.

ProtectControlGroups=yes
ProtectHostname=yes

are probably safe as well. So will add them too.


I uploaded those changes in rsyslog_8.2310.0-1

Please let me know, if you run into any issues.

Thanks everyone who provided feedback so far.

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053805: ITP: tremotesf2 -- Remote GUI for transmission-daemon

[Antoine Beaupre]

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

* Package name: tremotesf2
  Version : 2.4.0
  Upstream Contact: Alexey Rochev 
* URL : https://github.com/equeim/tremotesf2/
* License : GPL-3.0-or-later
  Programming Lang: C++
  Description : Remote GUI for transmission-daemon

Tremotesf is yet another, but modern (first-released in 2016)
cross-platfom GUI for Transmission daemon written in C++ and Qt.

Features include, but not necessarily limited to:
 * View torrent list
 * Sort torrents
 * Filter torrents by name, status and trackers
 * Start/stop/verify/remove torrents with multi-selection
 * Add torrents from torrent files and magnet links
 * Select which files to download when adding torrent
 * Manage torrent files
 * Add and remove torrent trackers
 * View torrent peers
 * Set torrent limits
 * Change remote server settings
 * View server statistics
 * Multiple servers
 * Supports HTTPS connection
 * Can connect to servers with self-signed certificates (you need to add
   certificate to server settings)
 * Client certificate authentication



The above description is taken from the FreeBSD port:

https://www.freshports.org/net-p2p/tremotesf/

There are other Transmission clients in Debian of course, but the best
one (the official "transmission-qt") has several release-critical
bugs, including crashes when adding new torrent files. It also doesn't
have as many features as the above, the one I am most interested in is
HTTPS.

Re: Please test apt-listchanges 4.0 in experimental

[Jonathan Kamens]

On 10/11/23 03:37, Alexandre Detiste wrote:

Le dim. 8 oct. 2023 à 17:27, Jonathan Kamens  a écrit :

I'd appreciate some testing from folks here before it gets promoted to unstable.

I got important NEWS from libx11 from  2006 (?)
so far so good for the rest.
Can you confirm that this occurred with 4.0 rather than 4.1? There's a 
bug-fix for at least one case of this in 4.1, but if you encountered 
this with 4.1 then perhaps there is another bug with the same symptoms 
that hasn't been fixed yet.

the database needs to be populated with data for existing packages during 
upgrades

Having a "solid" .timer forever for a single-time task seems a bit too much.
Could this be done a different way with "systemd-run"
or a .timer generated in /run/systemd/system ?
I believe both of these don't persist past a reboot. This needs to 
persist after reboot since rebooting immediately after an upgrade is common.

* Code cleanup and improvement, including `flake8' and `pylint'
   compatibility, (some) unit tests, and adherence to newer standards and
   best practices.

Can annotations/mypy testing be considered now "best practices" for
Debian native packages ?


Best practice? Sure. Requirement? Not so much.

Regarding apt-listchanges in particular, I have already spent countless 
hours getting ready for this new release, including the addition of a 
substantial unit-test suite where there were no tests before. I do not 
have the bandwidth to add type hints as well, and I do not think this 
should be a blocker to releasing the new version to the public.


I am happy to consider a MR if someone else wants to add typing to the 
code-base.


  jik

Re: [RFC] locking down rsyslog.service

[Michael Biebl]

Am 11.10.23 um 12:54 schrieb Sam Morris:

On 10/10/2023 19:22, Michael Biebl wrote:

I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives


Have you considered NoNewPrivileges=yes?

This is turned in implicitly by some of the other options (e.g,. 
PrivateDevices=yes) but only if running without CAP_SYS_ADMIN, so for it 
to be effective you'd have to set it explicitly.




Thanks. Will add it.

ProtectControlGroups=yes
ProtectHostname=yes

are probably safe as well. So will add them too.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [RFC] locking down rsyslog.service

[Sam Morris]

On 10/10/2023 19:22, Michael Biebl wrote:

I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives


Have you considered NoNewPrivileges=yes?

This is turned in implicitly by some of the other options (e.g,. 
PrivateDevices=yes) but only if running without CAP_SYS_ADMIN, so for it 
to be effective you'd have to set it explicitly.


--
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Re: [RFC] locking down rsyslog.service

[Simon Richter]

Hi,

On 10/11/23 19:14, Michael Biebl wrote:


- CAP_NET_ADMIN: use of setsockopt()
- CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max, the system-wide limit on 
the number of open files, in system calls that open files (e.g. accept 
execve), use of setns(),...


I see, thanks!

I looked over the code quickly, it seems the only privileged 
setsockopt() calls are to set larger buffer sizes.


It may be good to lobby for these and the open file limit to be added to 
CAP_SYS_RESOURCE, that would allow locking it down further in the future.


   Simon

Re: [RFC] locking down rsyslog.service

[Michael Biebl]

Am 11.10.23 um 08:03 schrieb Simon Richter:

Hi,

On 10/11/23 03:22, Michael Biebl wrote:


I intend to lock down rsyslog.service in Debian in one of the next
uploads using the following systemd directives



CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE
CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_SYS_ADMIN CAP_SYS_RESOURCE
CAP_SYSLOG


Does it actually need CAP_NET_ADMIN and CAP_SYS_ADMIN?

Everything else looks good to me.


The list is based on
https://github.com/rsyslog/rsyslog/pull/4999#issuecomment-1313362425

- CAP_NET_ADMIN: use of setsockopt()
- CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max, the system-wide limit on 
the number of open files, in system calls that open files (e.g. accept 
execve), use of setns(),...


I trimmed stuff like CAP_SETGID and CAP_SETUID, which the Debian package 
doesn't need.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Please test apt-listchanges 4.0 in experimental

[Alexandre Detiste]

Le dim. 8 oct. 2023 à 17:27, Jonathan Kamens  a écrit :
> I'd appreciate some testing from folks here before it gets promoted to 
> unstable.
I got important NEWS from libx11 from  2006 (?)
so far so good for the rest.


> the database needs to be populated with data for existing packages during 
> upgrades
Having a "solid" .timer forever for a single-time task seems a bit too much.
Could this be done a different way with "systemd-run"
or a .timer generated in /run/systemd/system ?


> * Code cleanup and improvement, including `flake8' and `pylint'
>   compatibility, (some) unit tests, and adherence to newer standards and
>   best practices.

Can annotations/mypy testing be considered now "best practices" for
Debian native packages ?

I see that testing of apt-listchanges would benefit from having
python3-debconf typed first.

I personally find annotations very usefull when handing over old, big codebases
to some new team who doesn't have the expected input type of function
in their head.
It also helps clean-up things that were jurry rigged for python2+3
compatibility. (bytes/str...)


I'm tempted to add for myself a RSS generator to apt-listchanges
on a private branch and see where it goes,
but would first would like it to be typed.

Greetings

Re: Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling

[Andrius Merkys]

Hi,

On 2023-10-11 10:18, Simon Richter wrote:

On 10/11/23 16:00, Andrius Merkys wrote:

Yes, but what does it do? Why would I pick this out of a package list 
if I didn't know the name of the package already?



The following line in the RFP says:


Vite is a frontend build tool, including development server and build 
command bundling code with Rollup, pre-configured to output optimized 
static assets for production.


That is the long description. I have to view the details for a package 
to access the long description, and it still does not tell me anything 
about the package that would help me make a decision whether I want to 
install it.


The most information is contained in the package name, which suggests 
that this belongs to the NodeJS ecosystem, and this is obvious to me 
only because I know that ecosystem exists and uses this naming 
convention within Debian.


I have no idea how it fits into that system, and which specific problems 
it solves, so even if I were a NodeJS user, I still could not use this 
to decide whether I want to install it.


The target audience for descriptions is "users who do not know the 
software yet."


You are right, I could have written a clearer description. I will 
rewrite it to better explain the purpose of the package.


Thanks,
Andrius

Re: Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling

[Simon Richter]

Hi,

On 10/11/23 16:00, Andrius Merkys wrote:

Yes, but what does it do? Why would I pick this out of a package list 
if I didn't know the name of the package already?



The following line in the RFP says:


Vite is a frontend build tool, including development server and build 
command bundling code with Rollup, pre-configured to output optimized 
static assets for production.


That is the long description. I have to view the details for a package 
to access the long description, and it still does not tell me anything 
about the package that would help me make a decision whether I want to 
install it.


The most information is contained in the package name, which suggests 
that this belongs to the NodeJS ecosystem, and this is obvious to me 
only because I know that ecosystem exists and uses this naming 
convention within Debian.


I have no idea how it fits into that system, and which specific problems 
it solves, so even if I were a NodeJS user, I still could not use this 
to decide whether I want to install it.


The target audience for descriptions is "users who do not know the 
software yet."


   Simon

Re: Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling

[Andrius Merkys]

Hi,

On 2023-10-11 09:44, Simon Richter wrote:

On 10/11/23 15:30, Andrius Merkys wrote:


   Description : Next Generation Frontend Tooling


Yes, but what does it do? Why would I pick this out of a package list if 
I didn't know the name of the package already?


The following line in the RFP says:

Vite is a frontend build tool, including development server and build 
command bundling code with Rollup, pre-configured to output optimized 
static assets for production.


Andrius