Re: Bug#1010013: ITP: python-websocketd -- Python module for creating a http server which uses WebSockets
Hi, On Fri, Apr 22, 2022 at 05:56:08PM +0200, Andrej Shadura wrote: > I don’t want to discourage you from packaging this, but unless I’m mistaken, > this will be at least the third Websocket client package for Python, and at > least the third Websocket server in Python 🙂 Yes, I'm not surprised. I have used my module for years and it has other users as well, so I think it is valuable to have it in Debian. End users cannot simply swap out one of them for another, so the argument "we already have that" doesn't apply for libraries/modules. Thanks, Bas signature.asc Description: PGP signature
Re: RFC: pam: dropping support for NIS/NIS+?
> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek > said: > If your users are using yppasswd on the NIS master for changing passwords, > then evidently you are not relying on support for NIS in PAM. (yppasswd > doesn't even link against libpam.) Thanks for clarifying this. -- regards Thomas
Re: RFC: pam: dropping support for NIS/NIS+?
> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek > said: > NIS also dates from a period when rsh was considered acceptable, and unless > I'm mistaken, has a comparable level of security. Allowing access to > password hashes for users based on the IP of the machine you are querying > from is not a sane security policy, and I don't think we should indefinitely > make Debian worse for all other users (bigger minimal system == worse) to > cater to users of these obsolete, insecure systems. A normal user does not see the password hashes, only processes which can use a port < 1024 see the password hash in the NIS map. So I do not see a problem giving machines of a subnet (based on their IP) access to the NIS data, when I can make sure only permitted computers can access the network. This does not give all users of this machine access to the password hashes. -- regards Thomas
Re: RFC: pam: dropping support for NIS/NIS+?
> On Fri, 22 Apr 2022 13:41:50 -0700, Steve Langasek > said: > If your users are using yppasswd on the NIS master for changing passwords, > then evidently you are not relying on support for NIS in PAM. (yppasswd > doesn't even link against libpam.) Thanks for clarifying this. -- regards Thomas
Re: RFC: pam: dropping support for NIS/NIS+?
Hi Thomas, On Fri, Apr 22, 2022 at 10:07:52PM +0200, la...@debian.org wrote: > I'm using NIS since 20+ years in a small network with about 60 computers. > Since I manage all computers and the physical network can be seen as secure > (I know it's not perfect secure) I do not need the additional crypto > features of NIS+ or LDAP, which would be overkill. All my users use > yppasswd on the NIS master for changing their password. I guess I > still need pam support for this because I set things like this in > pam.d/common-password: > passwordrequisite pam_cracklib.so retry=3 > difok=3 minlen=14 > Yes, I surely would miss the NIS support. If your users are using yppasswd on the NIS master for changing passwords, then evidently you are not relying on support for NIS in PAM. (yppasswd doesn't even link against libpam.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: RFC: pam: dropping support for NIS/NIS+?
Hi, I'm using NIS since 20+ years in a small network with about 60 computers. Since I manage all computers and the physical network can be seen as secure (I know it's not perfect secure) I do not need the additional crypto features of NIS+ or LDAP, which would be overkill. All my users use yppasswd on the NIS master for changing their password. I guess I still need pam support for this because I set things like this in pam.d/common-password: passwordrequisite pam_cracklib.so retry=3 difok=3 minlen=14 Yes, I surely would miss the NIS support. -- regards Thomas
writing good GR ballots (Re: Firmware - what are we going to do about it?)
On Wed, Apr 20, 2022 at 10:52:04AM -0700, Russ Allbery wrote: > I agree with this option split, but that reminds me of a different > procedural note. > > While I recognize and respect the desire to create a comprehensive ballot, > I'm still going to advocate for proposing a GR only with the options that > the person proposing the GR would vote above NOTA, and possibly only your > preferred options. > > There are a couple of reasons for this. One is that the people who prefer > your disfavored options may have their own way of wording them that's > slightly different than what you might believe they would want to say, and > it's awkward to update other people's ballot options. The other, somewhat > more technical reason is that I expect this GR to require a 3:1 majority > for some options, and mixing 3:1 and 1:1 majority options on the same GR > can be rather confusing. We may end up needing to do that anyway for this > vote, but I think it would be a good idea to avoid creating the problem > unless someone steps forward and proposes a 1:1 option that they really > want to win. > > (That said, I think there's a big exception, which is that if you've > canvassed a bunch of people who may not want to try to craft their own > ballot options, and developed options to reflect their views, I think > that's a fine approach and a good reason to propose options that aren't > your personal preference.) > > As a side note, I don't remember exactly how this worked before, but under > the current constitutional rules the original GR proposer doesn't have a > special ability to put a bunch of options on the original ballot. You > start with one option, and then you can add more options but they all need > to be sponsored independently. So that also pushes in this direction of > ballot construction. would it make sense to document this (and more) somewhere as 'guidelines for writting good GR ballots' or some such? I'd guess the wiki would be a good starting point or maybe somewhere else? does this exist already -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The entire society has no clue what the word freedom means in the context of relating to the world around them. It has degenerated into "my ego first". It is why the entire planet is dying right now. signature.asc Description: PGP signature
Bug#1010013: ITP: python-websocketd -- Python module for creating a http server which uses WebSockets
Package: wnpp Severity: wishlist Owner: Bas Wijnen X-Debbugs-Cc: debian-devel@lists.debian.org, wij...@debian.org * Package name: python-websocketd Version : 0.2 Upstream Author : Bas Wijnen * URL : https://github.com/wijnen/python-websocketd * License : AGPL3+ Programming Lang: Python Description : Python module for creating a http server or client which uses WebSockets This module uses the network module to create a server, and implements http(s) and WebSockets over those connections. With only 6 lines of code you have a working system. You only have to add what you want your server to do. . It also provides a client socket, which can be used to communicate with such a server. I use this module for many of my networked programs. It requires python-network (#1010012) and python-fhs (#1010010).
Re: Firmware - what are we going to do about it?
hi Steve, On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote: > TL;DR: firmware support in Debian sucks, and we need to change this. See the > "My preference, and rationale" Section below. [...] and anyone involved, especillay including those not listed here: > Thanks to people who reviewed earlier versions of this document and/or made > suggestions for improvement, in particular: > > • Cyril Brulebois > • Matthew Garrett > • David Leggett > • Martin Michlmayr > • Andy Simpkins > • Neil Williams I just wanna say THANK YOU VERY MUCH for this thread and everything good which will undoubtfully arise from it. You rock. And for those unware I would just like to point out https://en.wikipedia.org/wiki/Intel_ME#Hardware which explains that on modern Intel CPUs, there's another 386 CPU inside the CPU, running Minix, so that "The ME has its own MAC and IP address for the out-of-band interface, with direct access to the Ethernet controller; one portion of the Ethernet traffic is diverted to the ME even before reaching the host's operating system". My point is not, that other CPUs don't have this problem, but rather that there's a lot of 'invisible' firmware on any modern computer, starting with the CPU but going down all the way to the battery, screen, mouse and keyboard. So this thread is (roughly guesstimated) only about 10-23% of the firmware running on your computer, while today (as opposed to 1993) most of this firmware *can* be updated. IMO firmware is (sadly or not) somewhat out of scope for Debian. Even though, or maybe precisely because hardware *is* software nowadays. So, I'll say it again: many thanks to everyone involved in improving running Debian on modern computers. And huge thanks to those working on free and open hardware too. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ War is peace. Freedom is slavery. Covid is like the flu. signature.asc Description: PGP signature
Bug#1010012: ITP: python-network -- Python module for easy networking
Package: wnpp Severity: wishlist Owner: Bas Wijnen X-Debbugs-Cc: debian-devel@lists.debian.org, wij...@debian.org * Package name: python-network Version : 0.2 Upstream Author : Bas Wijnen * URL : https://github.com/wijnen/python-network * License : AGPL3+ Programming Lang: Python Description : Python module for easy networking Implementing networking in C is a pain. Unfortunately, much of that pain is copied to Python. This module instead tries to follow the "batteries included" approach, like the rest of Python. With this module, networking is a piece of cake. It can use tcp sockets and unix domain sockets and supports avahi and ssl connections without hassle. . This module provides a Socket class and a Server class. The Server creates Sockets when accepting connections; Sockets can be created by the user to initiate a connection. All of this is symmetrical: once the connection is established, the client and server use the same interface. . For providing RPC functionality in a language independent way, see python3-websocketd. I use this module for many of my programs, usually in combination with python-websocketd, for which I'll file an ITP after this. It requires python-fhs, for which I just filed #1010010.
Bug#1010010: ITP: python-fhs -- Python module for using the FHS and XDG basedir paths.
Package: wnpp Severity: wishlist Owner: Bas Wijnen X-Debbugs-Cc: debian-devel@lists.debian.org, wij...@debian.org * Package name: python-fhs Version : 1.0 Upstream Author : Bas Wijnen * URL : https://github.com/wijnen/python-fhs * License : AGPL3+ Programming Lang: Python Description : Python module for using the FHS and XDG basedir paths. The FHS and XDG basedir specification defines locations for several files. This module provides functions for accessing those files without requiring the program to search the filesystem itself. It provides a convenient way to use configuration from files, with commandline override functionality. I use this for most of my Python programs. It is also depended on by python-network and python-websocketd, which I will file an ITP for after this.
Re: Firmware - what are we going to do about it?
Leandro Cunha writes: > Hi, > > On Mon, Apr 18, 2022 at 9:28 PM Steve McIntyre wrote: >> >> TL;DR: firmware support in Debian sucks, and we need to change this. See the >> "My preference, and rationale" Section below. >> >> In my opinion, the way we deal with (non-free) firmware in Debian is a mess, >> and this is hurting many of our users daily. For a long time we've been >> pretending that supporting and including (non-free) firmware on Debian >> systems >> is not necessary. We don't want to have to provide (non-free) firmware to our >> users, and in an ideal world we wouldn't need to. However, it's very clearly >> no >> longer a sensible path when trying to support lots of common current >> hardware. >> >> Background - why has (non-free) firmware become an issue? >> = >> >> Firmware is the low-level software that's designed to make hardware devices >> work. Firmware is tightly coupled to the hardware, exposing its features, >> providing higher-level functionality and interfaces for other software to >> use. >> For a variety of reasons, it's typically not Free Software. >> >> For Debian's purposes, we typically separate firmware from software by >> considering where the code executes (does it run on a separate processor? Is >> it >> visible to the host OS?) but it can be difficult to define a single reliable >> dividing line here. Consider the Intel/AMD CPU microcode packages, or the >> U-Boot firmware packages as examples. >> >> In times past, all necessary firmware would normally be included directly in >> devices / expansion cards by their vendors. Over time, however, it has become >> more and more attractive (and therefore more common) for device manufacturers >> to not include complete firmware on all devices. Instead, some devices just >> embed a very simple set of firmware that allows for upload of a more complete >> firmware "blob" into memory. Device drivers are then expected to provide that >> blob during device initialisation. > > I'm from the group that defends Debian current position on this and I > like to install only what the machine needs to work and I use free > firmware on my machine for the wireless network card for example. I > don't see it as a mess, but it's organized by separating what's free > from what's not. The question of identifying what firmware my machine > needs, this for me is easy and it was just a question I had to learn > in the beginning many years ago. It is a problem for some and not for > all. There is the unofficial installer that solves this problem by > installing only what the user's machine needs without the user doing > it himself. I understand the urge to insist upon absolute DFSG purity in the media we produce, but when it comes to wanting to avoid every last shred of data that we could not regenerate ourselves, I think we crossed that line some time ago. I'm thinking of shim-signed, which is included in our official media. Despite being free software in source form, it is signed by Microsoft, and can only be expected to work with that signature ... which we cannot create. On most (all?) hardware one is able to avoid UEFI secure-boot, so won't need to use shim-signed, but I'd imagine that some hardware insists on secure-boot, or the opt-outs are somehow broken and so is not usable without shim-signed. This seems rather similar to the situation with non-free-firmware, which many people can avoid the need for it, but without it some people find our software useless on the hardware they have. Is the presence of shim-signed on the install media enough to make people feel somehow contaminated? If not, is the problem having other blobs of data on the media that we also cannot generate, or is it the licensing of that data, or something else? Does it make any difference that the data in question will not be read into memory, or copied onto the target system, unless one opts-in to using it? Anyway, thanks to Steve for starting the discussion. Cheers, Phil. P.S. I think that having some (often unused) data on the media that allows people to install our software when they'd otherwise fail is more important than absolute purity in this case. I do not think there is an increased risk of non-free contamination here. If it ensures that fewer people abandon Debian out of frustration with the install then I'd suggest that it will actually result in less non-free software being used overall, as will having the option to enable only non-free-firmware without also enabling non-free. Oh, and I've been a DD for over 25 years, have been a contributor to the installer for quite a lot of that, so I'd hope that at some point during that time I must have succeeded in doing the add-firmware dance, if only for testing, but wouldn't dream of relying on that as my real install method, or recommending it to a newbie. Frankly, it makes me wince every time I have to respond with a confusing answer to the "What do
Bug#1010003: ITP: dynamic-motd -- gives some informations when you log into a server through SSH
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: dynamic-motd Version : 0.04 Upstream Author : Luc Didry * URL : https://github.com/ldidry/dynamic-motd * License : GPL-2 Programming Lang: Python Description : gives some informations when you log into a server through S dynamic-motd replaces the standard /etc/motd prompt by a more dynamic thingy, which is also modular, so you can customize the SSH motd with information from your system.
Re: Firmware - what are we going to do about it?
Am 22. April 2022 07:18:50 MESZ schrieb Andreas Tille : >Am Thu, Apr 21, 2022 at 10:12:19AM -0700 schrieb Russ Allbery: >> >> I've been a Debian Developer for quite some time and can usually manage to >> figure out most tasks like this, and providing separate firmware to the >> installer has completely defeated me every time I've tried it. > >I confirm that I never ever managed to provide the needed firmware to >the free official installer. This is just a "me too". (similar to Russ and Andreas) I have spent many years with Debian (~25 for me), and if the old folks can't manage to use the free official installers, then I think/agree that it's outright hypocrisy to nudge new users into this pitfall. I'd be very happy with option 5, and I'm in the camp of those who like a strictly opt-in solution (that can be preseeded) mfh.her.fsr IOhannes
