Re: Suggestions about i386 support
On Sun, 19 May 2024 20:19:12 +0200, Ben Hutchings wrote: >The plan is to keep i386 as a partial architecture that can be used as >a "foreign architecture" on systems where amd64 is the main >architecture. Many people using ancient hardware such as a T60 thinkpad say that's not enough for them. I can partly understand both sides though. Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: About i386 support
On Sun, 19 May 2024 15:03:18 +0200, Victor Gamper wrote: >I believe I could swap out the processor on my T60, >however, I'd both need to have that processor and >make sure that it is actually possible. It still would >not really make sense on a platform that only supports >3G of physical RAM. > >Anyways, if the only reason why i386 cd images are not >supported anymore is the lack of contributors, >I'd be willing to contribute in that area, if it's possible. If you don't personally care about that T60, because it's the notebook your mom gave you for your 16th birthday or so, you would probably be better served with buying another old T-Thinkpad that can run amd64 AND suport amounts of memory that haven't totally fallen out of time. Ten year old 64bit Notebooks such as the T420 or T430 (three years younger than your T60) sell for below 100 Euros. Is that a problem? Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: Any volunteers for lintian co-maintenance?
On Thu, 09 May 2024 13:57:28 -0700, Soren Stoutner wrote: >However, I personally find lintian to be one of the most helpful tools in >Debian packaging. +1. The fact that it doesn perform well on large packages is bad, but that doesnt make it less useful for smaller packages. Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Tue, 07 May 2024 22:29:30 +0100, Richard Lewis wrote: >Holger Levsen writes: >> I'm a bit surprised how many people seem to really rely on data in /tmp >> to survive for weeks or even months. I wonder if they backup /tmp? > >I use /tmp for things that fall somewhere between "needs a backup" and >"unimportant, can be deleted whenever". For me there is a difference between /tmp and /var/tmp. On all my systems, /tmp has been a tmpfs for decades, /var/tmp being used for data that is too large for tmpfs. Even losing /tmp would probably affect some of my running programs including the X11 session. Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: finally end single-person maintainership
On Wed, 10 Apr 2024 22:44:25 +0200, Andreas Tille wrote: >'Require' is probably the wrong word. I simply have heard from several >potential young contributors that they feel blocked by the tooling and >specifically not everything in Git. That does not only apply to young contributors. I am an old fart and I still shy back from packages where I need to familiarize myself with an uncommon packaging toolchain. >> then pull them, >> maybe into different branches, > >git-buildpackage maintains two or three branches: The main packaging >branch and an upstream branch. The pristine-tar branch is optional (but >default in the teams I'm working in) And not (any more?) default in the tools, thus easily forgotten. Greetings MArc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: finally end single-person maintainership
On Tue, 9 Apr 2024 20:51:45 +0200, Gioele Barabucci wrote: >Asking maintainers "to use git" means: please push your changes, even >those unreleased to a public git repository (salsa, github, codeberg, >your own domain...), so other people can contribute 1) knowing that they >are working against the same sources the maintainer has on their hard >drive, and 2) using git-based workflows. To have this actually work, I'd like to have published best-practice things such like "branches with a 'wip-' prefix can have their history rewritten any time" so that I can use git rebase --autosquash --interactive to fix my commit errors even on branches that I have already pushed without feeling bad for doing so. >dgit is both a Web interface to browse git repositories as wells as a >system to access the Debian archive as if it were a git repository, so >you can "dgit push" a branch and have the resulting binary uploaded to >the archive. (Yes, I'm simplifying here, but that's the gist.) It is also not well documented for a beginner. I think that the dgit docs are fine for someone who is already familiar with the tool and has been using it for some time, but I have tried to read myself into dgit multiple times and utterly failed with that. >Salsa is a forge, i.e. a combination of a Web interface, a git server, >and a set of integrated features. In comparison to dgit, salsa has, like >most forges: > >* Merge requests: where people can suggest changes and discuss them with >line-based comments (accessible via email, no need to use the Web interface) > >* Continuous integration pipelines: as soon as you push a commit, >Salsa-CI will try to build a package, cross build it, test it against >piuparts, lintian a bunch of other QA tools (kudos to the Salsa-CI >developers). > >* Integrations with two dozen tools (irc, jenkins, mattermost, bugzilla, >but funnily enough not BTS). > >* Project specific wikis, snippets, Docker images. > >* And with tag2upload salsa fulfills 50% of dgit functionality. And, a web interface which make the learning curve a lot less steep. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: finally end single-person maintainership
On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel wrote: >Also regarding gbp, my packaging workflow does not require it >(debian/-folder-only in Git). Being enforced to use some other pkg'ing >style would reduce my fun and end up with less productivity, I fear. >The gbp workflow has its pros, but for me it is a too complex overhead >without much gain to the end result (the uploaded package). The debian/-only layout was quite common in the svn days and back then we had adequate tooling to support that but those tools have rotted away, it feels unnatural to me, and, frankly, exim's debian/-only layout (that I introduced myself fifteen^wtwenty years ago) is the main reason why I am a mostly inactive member on the exim team since I still don't know any more how to properly build the package. Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: finally end single-person maintainership
On Tue, 9 Apr 2024 18:37:23 +, Holger Levsen wrote: >- I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Agreed. > Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. Agreed. It is too easy for three singel maintainers to form a pro forma team where everyone works on their packages and not on the others'. You cannot enforce team work. Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
About Package Maintenance (was: Question to all candidates: What are your technical goals)
This is the continuation of a thread from debian-vote, that originated
from a question about technical goals to the DPL candidates
(https://lists.debian.org/debian-vote/2024/04/msg4.html).
I will try to quote generously to deliver context.
On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote:
> Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber:
> > On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
> > > I see a big problem that we do not follow common standards. While we
> > > have some teams with strict policies setting those standards internally
> > > to a different level of strictness there is no Debian wide consensus
> > > about things like
> > >
> > > A. Packages should be maintained on Salsa
> > > B. Lets use dh (if possible - I was told there are exceptions)
> > > C. Commit to latest packaging standards
> > > D. Make more than one person responsible for a package
> > > E. General QA work of contributors not mentioned as Maintainer /
> > > Uploader
> > >
> > > [I will reference these items below by their letters]
> > >
> > > I'm addressing this in the paragraph "Packaging standards" of my
> > > platform. I'm also very concerned about packages who don't get
> > > any attention any more ("smelly packages") which has two major
> > > reasons:
> > >
> > > 1. We do not have contributors with free capacity to care for
> > > problems in other peoples packages
> > > 2. Even if we had those the strict ownership of packages pevents
> > > that new contributors can step in. When reading the paragraph
> > > about NMUs in developers reference[1] this is probably
> > > sensible for actively maintained packages - but what about
> > > those packages which do not show any activity for years?
> >
> > I think this can't just be seen by looking at the statistiks. Many small
> > packages do their job and don't need constant attention as long as they
> > still build and work.
>
> I agree that pure statistics is not telling the whole story. However,
> those statistics give some feeling about the issue which for sure needs
> to be verified on case-by-case basis. I can assure you that I usually
> inspect the list of smelly packages[1] whether there are hits for my
> name (currently one false positive and one package where I'm forced to
> use cdbs) but also look for packages I might be able to salvage from
> there. I've found some impressive hits for this purpose in the past
> that are supporting my point besides stupid statistics.
I agree with your reasoning here, and I don't see an attack against my
packaging practise here. It is important feedback to me that will help
me to adjust my view on my duties as package maintainer.
[apg, console-log, dnstop]
> > Those three packages I decided not to put work into until there is a
> > technical reason for doing so. I do have all three on the radar and they
> > will properly move to salsa and be modernized once there will be a
> > change to the code or an RC bug regarding packaging. Until then, I have
> > more important things to do.
>
> Thanks for going into detail about these which I neither wanted nor
> expected in this granularity. I had no doubt that there are more
> important things for you. I honestly tried to investigate by using
> these examples is the following: In case there might be people out
> there who have time and energy to fix this kind of things, how can we
> enable them to take this work from your shoulders to enable you
> concentrating on more important stuff.
I'm always open to patches, MRs or more involvement of more people. I
doubt that thos three packages are going to get any in the future, and I
surely hope that any external help that I might get from others will be
regarding more important packages that I maintain like sudo or adduser.
I would like to elaborate a bit about adduser, where team collaboration
has worked like a charm.
I seldomly set myself in the Maintainer field any more, even if I am the
only person who has worked on the package in years. Having a
packages.debian.org mailing list in the Maintainer field enables random
people to subscribe to the full stream of package-related e-mails, which
allows interested parties to just peek in and see what's going on, and
also allows inofficial team building. For my most important packages, I
write about my plans to package@p.d.o and am soliciting for comments,
and I still do this while I know that I am mostly talking to myself.
In adduser, this has enabled two people to informally joint the team and
directly contribute. Sadly, bo
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Thu, 4 Apr 2024 13:25:04 +0200, Stephan Seitz wrote: >Am Di, Apr 02, 2024 at 13:30:43 +0200 schrieb Marc Haber: >>from being vulnerable to the current xz-based attack. Just having to >>dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to >>maintain a packet filter. > >Stupid question, but if you put „ALL: ALL” into hosts.deny, couldn’t you >stop the ssh daemon instead? ALL: ALL will block your ssh access, so it >doesn’t matter if the daemon is running or not. Of course there are sshd: lines in hosts.allow for "my" networks. Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Thu, 4 Apr 2024 13:03:50 +0200, Florian Lohoff wrote: >I personally moved to nftables which is nearly as simple once you get >your muscle memory set. So you have dedicated packet filters on every machine you run, even if sshd is the only network-facing service? Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Wed, 03 Apr 2024 14:10:37 +0100, "Jonathan Dowland" wrote: >On Tue Apr 2, 2024 at 12:30 PM BST, Marc Haber wrote: >> Please don't drop the mechanism that saved my¹ unstable installations >> from being vulnerable to the current xz-based attack. Just having to >> dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to >> maintain a packet filter. > >For you and fellow greybeards, perhaps: I'd be surprised if many people >younger than us have even heard of tcp wrappers. I don't think the >muscle memory of a diminishing set of users is a strong argument, >especially given it's a preference rather than a requirement, and >alternatives do exist. It is possible to have that alternative not present without being noticed (for example, a firewall build script failing, but sshd start nof failing), whilea security measure built into the very daemon is way harder to be accidentally disabled while keeping the daemon running. I have spent weeks if not months of my life building firewalls that fail to the safe side (have it "all closed" if something fails during build), lost them all when we got migrated to nft to do its inadequate tooling, while hosts.deny and hosts.allow is done in seconds even if you don't have orchestration. If there are arguments for keeping tcp-wrappers-compatible security in sshd, it is NOT muscle memory, it is a techincal founded and solid preference. Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, 2 Apr 2024 01:30:10 +0100, Colin Watson wrote: >We carry a patch to restore support for TCP wrappers, which was dropped >in OpenSSH 6.7 (October 2014); see >https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html >and thread. That wasn't long before the Debian 8 (jessie) freeze, and >so I patched it back in "temporarily", but then I dropped the ball on >organizing a proper transition. Please don't drop the mechanism that saved my¹ unstable installations from being vulnerable to the current xz-based attack. Just having to dump an ALL: ALL into /etc/hosts.deny is vastly easier than having to maintain a packet filter. Greetings Marc ¹ and probably thousands others -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 11 Mar 2024 07:02:38 +0200, Martin-Éric Racine wrote: >Meanwhile a bare minimal system needs a non-GUI solution and swaping >which DHCP client gets pulled by ifupdown is the simplest, least >disruptive way of accomplishing this. Most bare minimal non-GUI systems run fine with systemd-networkd in my world. Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)
On Mon, 11 Mar 2024 20:26:40 +, Holger Levsen wrote: >foo="bin1 >bin2 >bin3" > >$file=/some/path/to/bugreport_without_package_line.txt >tmpfile=$(mktemp) > >for package in $foo ; do > ( echo "package: $package" ; > cat $file ) > $tmpfile > do mutt -s "RM: remove $package" -i tmpfile $package > sleep 15m >done >rm $tmpfile > >with 40 packages this is just a 10h running script ;) A very nice example for Koehntopp's rule: "Verwende perl¹. shell will man können, dann aber nicht verwenden"² Greetings Marc ¹ it would be python nowadays, the saying is 25 years old ² "Use perl. You want to know how to write shell scripts, but not actually do it" -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: usrmerge breaks POSIX
On Thu, 15 Feb 2024 00:05:36 +0100, Vincent Lefevre wrote: >This is invalid. See > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168 That doesnt answer the question asked, it is a bug from 2016 that was fixed since then, and I am one of those who fails to see the connection between the subject of this thread and the nebulous claims you make in the messages AND obviously refuse to explain your reasoning if asked. Russ and Ansgar are among the brightest people in Debian, so if they don't understand what you mean, I suggest answering their question instead of throwing more fog. Greetings Marc -- ---- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: /usr-move: Do we support upgrades without apt?
On Thu, Dec 21, 2023 at 11:19:48AM -0300, Antonio Terceiro wrote: > On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote: > > Is it ok to call upgrade scenarios failures that cannot be reproduced > > using apt unsupported until we no longer deal with aliasing? > > I think so, yes. I don't think it's likely that there are people doing > upgrades on running systems not using apt. Do those GUI frontends that work via packagekit or other frameworks count as "using apt"? I now that WE recommend using apt in a text console outside of X, but even many of our own users do what their Desktop Environment does, and our downstreams like *b*nt* recommend other ways to upgrade as well. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Reaction to potential PGP schism
On Thu, 14 Dec 2023 23:00:41 +0100, Joerg Jaspert wrote: >On 17077 March 1977, Stephan Verbücheln wrote: > >> How can Debian deal with this? Should Debian intervene to prevent the >> worst? > >We, as Debian, look and wait what comes out. And then *MAY* at some >point decide to add (or switch to) a new thing, if that appears better. In summary, this is bad news for the security of people, since there will be ANOTHER competing and incompatible standard which will make finding a basis for communication significantly harder, raising the bar for a beginner even higher than it is already today. Sad Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: What would help the most?
On Fri, 27 Oct 2023 14:00:45 -0500, Lukasz Szybalski wrote: >What is the minimum most value thing that would help YOU accomplish your >goals for Debian ? I do not quite understand the question, so my answer might be a bit off. I'd like to have conffile management improved. Debian is already better than other distributions in this regard, but I'd still have a few additional features. For example having some kind of interactive merge function that could be invoked during package installation instead of the "do you want their conffile, your conffile, an editor or a shell" prompt. I'd like to have better tooling for conffile handling in maintainer scripts, some convergence of dpkg and ucf, possibly a more declarative approach or more boilerplate code that is easier to debug. And I'd like Debian packages to make consequent use of this mechanism which is one that makes Debian special. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Illegal Instruction Using sudo in Bookworm on i686
On Tue, 17 Oct 2023 10:57:41 -0500, Justin wrote: >Similar issue in Gentoo: >https://bugs.gentoo.org/show_bug.cgi?id=862201 ><https://bugs.gentoo.org/show_bug.cgi?id=862201> > >Similar issue in FreeBSD, more recent, but different processor: >https://forums.freebsd.org/threads/illegal-instruction-after-12-4-upgrade-i386.89353/ > ><https://forums.freebsd.org/threads/illegal-instruction-after-12-4-upgrade-i386.89353/> > >Relevant GCC commit: >https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=77d372abec0fbf2cfe922e3140ee3410248f979e > ><https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=77d372abec0fbf2cfe922e3140ee3410248f979e> The corresponding Debian issue are probably #1004893 and #1043281 which was boiled down to a GCC issue, #1005863 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 As the sudo maintainer, I am reluctant to turn off a hardening feature to support ancient CPUs. I would be reluctant to do that for a normal package, but ESPECIALLY for a package like sudo which is installed nearly everywhere and contains an suid root binary. I am willing to consider arguments and Ctte advice, but as things are now I am fine with the current state. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: /usr/-only image
On Tue, 12 Sep 2023 14:37:10 +0900, Simon Richter wrote: >The problem isn't so much the location of the configuration file, but >the method used to merge default, distro-provided and system-specific >configuration, and how much deviation from the default configuration is >expected. > >I'd argue that udev and systemd are kind of special here in that they >mostly provide a registry for other components to hook into, and that >the majority of users stick with the default configuration. I'd go so far that the systemd/udev way is a strategy to cope with nearly non-existent conffile handling on non-Debian distributions. We didn't do ourselves a favor by blindly adopting this scheme, while we're having a vastly superior package managed that handles conffiles and conffile changes so nicely. Please considernot throwing this advantage away for the rest of our distribution. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: DEP-5 copyright with different licenses for two parts of the same file
On Tue, 29 Aug 2023 09:45:36 -0700, Russ Allbery wrote: >This is the intended purpose of "and": cases where one file is covered by >multiple licenses simultaneously. Thank you. I missed the "Syntax" paragraph in the DEP-5 specification. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
DEP-5 copyright with different licenses for two parts of the same file
Hi, in daemon(1), I have a file with has two contradicting licenses in the same file. See https://salsa.debian.org/debian/daemon/-/blob/master/libslack/getopt.c >From the wording of the second copyright notice, I think it is clear that that notice applies to the POD documentation included in the file while the actual code is LGPL. Upstream confirms that this is the intention and agrees that this is somehow suboptimally worded. Now, how do I write this in a DEP-5 copyright file? Having two stanzas for the same file gets flagged by Lintian as an Error, and the DEP-5 syntax doesn't seem to allow to mention two Licenses in the License: line. Any hints woule be appreciated. Greetings Marc -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: DEP 17: Improve support for directory aliasing in dpkg
On Thu, 27 Apr 2023 12:53:31 +0200, Helmut Grohne wrote: >failing >our Code of Conduct The thread went CoC and died. End of discussion for me. -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Upgrade package from init script to Systemd, move config folder
On Thu, 27 Apr 2023 08:20:34 +0200, Simon Richter wrote: >On Wed, Apr 26, 2023 at 04:25:19PM +0200, Marc Haber wrote: >> I am not sure whether it is doing non-systemd users a favor to keep a >> probably outdated, bitrotting and untested init script in the >> canonical place. My gut feeling is that it might be better to ship the >> old init script in /usr/share/doc/package/examples unless the package >> maintainer is reasonably sure that the init script will actually work. > >No, that is worse, because if an updated init script is shipped as an >example only, I will not even get a notification that I might want to >change my installed init script. You have a point here. Maybe it would be a good idea to have a standardized function in /lib/lsb/init-functions that emits a warning that the package maintainer has changed the mechanism to invoke the daemon and that the init script might need additional work, so that a lazy maintainer like me might just call that function to give the local admin a heads-up. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: DEP 17: Improve support for directory aliasing in dpkg
On Thu, 27 Apr 2023 07:58:35 +0200, Simon Richter wrote: >On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote: >> At some point the question becomes: Do we want that complexity inside >> dpkg (aka DEP 17 or some variant of it) or outside of dpkg (i.e. what >> we're talking about here). It seems clear at this time, that complexity >> is unavoidable. > >My gut feeling is that returning to "dpkg's model is an accurate >representation of the file system" will be less complex to manage >long-term. For this to work, the model needs to be able to express >reality, so I guess we can't avoid updating dpkg. My gut feeling is that we are wasting prescious time of numerous skilled Debian Developers to find ugly workarounds to something that should be done in dpkg, but isnt being done because one dpkg maintainer has decided to not go the way the project has decided to go. This inability to find consensus, to take decisions, accept and follow them is one of the most central problems that Debian has. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Upgrade package from init script to Systemd, move config folder
On Mon, 24 Apr 2023 15:48:02 +0100, Matthew Vernon wrote: >One thing I'd say is: please keep the init script in your package, so >that people using inits other than systemd can continue to use it. I am not sure whether it is doing non-systemd users a favor to keep a probably outdated, bitrotting and untested init script in the canonical place. My gut feeling is that it might be better to ship the old init script in /usr/share/doc/package/examples unless the package maintainer is reasonably sure that the init script will actually work. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Bug#995189: RFH: isc-dhcp
On Tue, 07 Mar 2023 20:26:20 +0100, Ansgar wrote: >Only the client and relay are no longer maintained upstream. The server >is still maintained and there is no need to drop it from Debian. They pulled the plug on relay and client from now to immediately, with no obvious replacement on the relay side, and then announced EOL for the server for end of 2022, leaving the world without the reference implementation. This is really bad. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Yearless copyrights: what do people think?
On Wed, 22 Feb 2023 15:40:49 +0100, Jonas Smedegaard wrote: >Quoting Daniel Baumann (2023-02-22 14:30:11) >> while having copyright information centrally available per package in >> d/copyright is definitly a usefull service, is providing the *years* >> really a service worth providing? >> >> personally I don't think so: for packages with non-trivial d/copyright, >> it's a significant effort to keep the years in sync with the upstream >> sources. > >Ensuring that debian/copyright stays correct take some effort, but that >is required to re-examine anyway for each new upstream release. > >I dare question that examining copyright *years* in particular is >noticably larger effort than the general required examination. If copyright inspection is like three quarters of the effort necessary to get, for example, a new sudo into Debian, then we are doing things wrong and setting our priorities wrong. This is indrecibly frustrating and time consuming busy work that doesn't require my qualification at all, and I REALLY have other things to do than that. It is especially frustrating when we're obviously being holier than the pope, when for example translators submit translations for very obviously non-FSF software with "Copyright Free Software Foundation" or with boilerplate copypaste headers stating a license that is totally different from the package that is being translated etc. Strictly, as a maintainer I MUST reject such translations because a po file also contains work by the original author which a translator cannot arbitrarily relicense, not even accidentally by just not paying proper attention. >> (and I doubt that all our source packages have accurate d/copyright, >> even less so when it comes to the year-information.) Amen. While I understand that having debian/copyright is vitally important, we NEED to relax our rules to reduce the effort necessary since it's demotivating busy work that I feel noone cares about. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Configuration files, local changes, and "managed section" markers
On Tue, 14 Feb 2023 11:23:55 -0800, Russ Allbery wrote: >I think the right answer (which as is often the case involves a lot more >work) is to break the configuration file into separate parts, one of which >is a true configuration file in the Policy definition and the other of >which is the settings that are needed by the upstream software but that >aren't a configuration file in the Debian sense (and thus aren't >user-modifiable), put the latter in /usr, and convince the program to load >them both in some way. I must say that I really like the idea of having "managed sections", allowing half-conffiles which is much easier to handle for non-complex cases where configuration is just a few lines and which would appear overly complex if we'd split that into conffile and non-conffile. The "split it" approach is something that comes naturally to someone who has been heavily socialized in the Debian Universe because we handle conffiles on a file level. It feels unnatural and clumsy for someone who is not familiar with the deep historic reasons for us to do it like that. The issue is, however, a lot more complicated than one would might think, imagine a structured configuration file like a systemd unit or an icinga or bind or ISC DHCP config file which would need multiple "managed sections", and the special case of a setting moving from managed to non-managed in the package or at the local admin's discretion. <---rant---> On the other hand, putting non-changing configuration in /usr reminds me of the systemd way to handle things, with a complicated combination of "if an identically named file is in /etc, it overrides the package-delivered configuration entirely without the local admin noticing that there was an upstream change" and "put configuration snippets in a magic place in /etc and it will augment the package-delivered configuration without the local admin notiting that the upstram changed in a way that is incompatible with the local augumentation". This way to handle things was of course invented in the Red Hat world because rpm's conffile handling is so vastly inferior to what we have available for 25 years now, and sadly we have taken this over 1:1 into Debian, not making use of your vastly superior methods here in favor of being compatible with Red Hat's worse solution. >If the right fix isn't available, I would be tempted to convert the whole >configuration handling to ucf or something similar that has built-in >functionality to try to handle cases like this. ucf is actually what dpkg should have been, I'd recommend it wholeheartedly, but we need more automation for that. Debian's way to handle conffiles is the best the Linux world has. That doesn't mean that we don't have room to improve. And sadly, we haven't moved a single inch here in 15 years. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: need we support unshadowed passwords from the installer
On Fri, 13 Jan 2023 21:11:40 -0500, nick black wrote: >i'm absolutely not suggesting we stop supporting NIS or other >programs which rely on unshadowed passwords. it's a big ol' >tent, and we have more than enough room for you to carry forth >the torch of Solaris 2. i just don't think this belongs in the >installer anymore. Amen. NIS-based systems usually have professional administrators who are well able to change the configuration. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Help setting dbconfig-common for MariaDB, not MySQL
On Mon, 2 Jan 2023 17:08:25 +0100, Paul Gevers wrote: >Hi Marc, > >On 02-01-2023 16:58, Marc Haber wrote: >> On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers >> wrote: >>> On 02-01-2023 14:21, Alessandro Vesely wrote: >>>> A user complained that MySQL doesn't work, because it misses the INET6 >>>> type that the example settings use. >>> >>> And is this an absolute must? (It's an example after all?) >> >> It is. We need to stop having "disable IPv6" as measure 1 if something >> doesn't work right. It's the default IP protocol for a decade. > >Are you saying that MySQL doesn't support IPv6? Or just that the "INET6 >type" in the context of MariaDB is a MariaDB specific implementation of >something? (Sorry, I didn't investigate and assumed the latter). I didn't investigate and assumed some kind of the former. Anyway, since we have a diversion between MySQL and MariaDB here that causes dbconfig-common to trip over an IPv6 issue, I see the usual solution coming over the horizon and wanted to object against that one. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Help setting dbconfig-common for MariaDB, not MySQL
On Mon, 2 Jan 2023 16:31:17 +0100, Paul Gevers wrote: >On 02-01-2023 14:21, Alessandro Vesely wrote: >> A user complained that MySQL doesn't work, because it misses the INET6 >> type that the example settings use. > >And is this an absolute must? (It's an example after all?) It is. We need to stop having "disable IPv6" as measure 1 if something doesn't work right. It's the default IP protocol for a decade. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Mon, 28 Nov 2022 15:50:56 +, Benjamin Drung wrote: >On Tue, 2022-07-19 at 08:49 +0200, Marc Haber wrote: >> We implemented that change last week, and promptly a bug report >> (#1014901) appeared, giving what we consider good arguments to change >> this back to 0700. Here is what the adduser team considers possible >> documentation for this, and we itend to include this in NEWS.Debian as a >> rationale for the change. >> >> [...] >> >> As mode 0700 provides both the most secure, unsurprising default, and is >> in line with most other major distributions, the adduser team considers >> the matter to be settled; any further discussion should come prepared >> with rationale, support, convincing use cases and a significant public >> discussion period. > >Ubuntu changed the default DIR_MODE to 0750 in January 2021 [1] with the >same intention than Debian now. I like to see Debian and Ubuntu agree on >one default DIR_MODE to keep the package difference small and make >documentation shareable. See NEWS.Debian for adduser 3.123 and the "default for DIR_MODE" chapter in https://salsa.debian.org/debian/adduser/-/blob/master/debian/README ¹. I am tired of this discussion and will not change this decision until overridden by the ctte. Greetings Marc ¹ the next upload will have this README actually installed to the package, I apologize for this bug -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: transition to usrmerge to start around 2022-09-15 (next Thursday)
On Sun, 11 Sep 2022 11:08:44 -0400, Marvin Renich wrote: >* Ansgar [220910 09:37]: >> the transition to usrmerge as described in [1] is planned to start >> around 2022-09-15 (next Thursday). >[snip] >> We will send an announcement to debian-devel-announce@ once the upload >> to unstable happens. > >What is the point in waiting until after the upload to send to >debian-devel-announce? I would think that most users running >testing/unstable would want prior notice, and you shouldn't assume that >all users will read their mail before performing a routine >update/upgrade cycle on the morning after the upload. I don't think >everyone running testing/unstable reads debian-devel, so I think it >would be appropriate to send to -announce at least one (two?) day(s) >before the upload. And, is there a solution for the existing conflict with the dpkg maintainer? Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
On Mon, 29 Aug 2022 00:15:27 -0400, Scott Kitterman wrote: >If I look at a package and determine it's only in New due to a new binary >package name and that means the project has prohibited me from looking for >other issues in the package until some time later when it's not in New, then I >feel pretty precisely like I'm prohibited from doing something. You could just not look at the packagein binNEW until you, with your private hat on, had the time to look at the copyright file before putting the ftpmaster hat on back again. Can mere mortals look at packages in binNEW to inspect them for bugs in debian/copyright? Of course, that would just circumvent the decision of the project and not gain us anything. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Epoch for node-markdown-it
On Mon, 22 Aug 2022 14:55:13 +0200, Wouter Verhelst wrote: >Someone using 22.something rather than 12.something in a version number, >to me, sounds like someone making a "serious mistake". > >So this is *exactly* what epochs are meant for! Exactly my feeling. In the last years, we have been taking away the reasons for using epochs one by one, making me wonder whether we should keep that component of our version numbers in the first place .. >The something+reallysomethingelse convention is evil and should never >have been invented in the first place. It's extremely confusing to >users, and an epoch is *hidden* from them. ... because it has been totally confusing to me since I started using Debian that epochs are not always shown. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: adduser default for sgid home directories
On Wed, 27 Jul 2022 16:10:18 +0200, Wouter Verhelst wrote: >On Mon, Jul 25, 2022 at 07:06:59PM +0200, Marc Haber wrote: >> I don't like the idea of messing with old NEWS entries at all. > >I'm trying to understand why you feel this way. It feels like rewriting history. Maybe the similiarity of the format to debian/changelog AND the fact that the same tool is used to edit supports that. [correct rationale snipped] Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: adduser default for sgid home directories
On Mon, 25 Jul 2022 09:05:55 -0700, Josh Triplett wrote: >Matt Barry wrote: >> On Mon, 2022-07-25 at 14:37 +0100, Colin Watson wrote: >> > On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote: >> > > Anyway, its been released at this point, so the issue is moot :) >> > >> > Regardless of the rest of the discussion, this isn't entirely true. >> > Yes, people following unstable will have already seen the NEWS entry >> > and >> > apt-listchanges won't show it again for that version, but it's still >> > possible to edit it retroactively so that (for example) people >> > upgrading >> > between stable releases see improved text. That can sometimes be >> > worthwhile. >> > >> >> That is a good point, and probably something we should plan to do. > >In particular, it may make sense to edit this NEWS entry and the >previous one, to avoid presenting two entries to stable users for two >different successive changes, rather than just one effective change. I don't like the idea of messing with old NEWS entries at all. In this case, an exception might be warranted, but we need to have the long explanation somewhere in the package for the next round of this issue that is expected in the 2030ies. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Please test adduser from experimental
Hi, the adduser team has recently done an experimental upload fixing another bunch of long-standing bugs. Those changes might influence adduser's behavior in package maintainer scripts and I would like to ask you to try adduser 3.124 from experimental if you do "weird things" with groups in your maintainer scripts or if you are using group-related configuration in adduser.conf. The changes will also affect the way new non-system users are placed into their respective groups. The most important things that were changed are: - We have clarified adduser's behavior regarding primary and supplemental groups. - If USERGROUPS=no, it is now possible to specify the group for all users either with its GID or with its name (USERS_GROUP vs USERS_GID) - If USERGROUPS=yes, USERS_GROUP and USERS_GID will be used to specify a supplementary group - it is also possible to not have a group for all users at all - --add_extra_groups is now --add-extra-groups for consistency of option spelling (old spelling still allowed, but deprecated) - there is now a --firstgid and a --lastgid option to influence the GIDs chosen for usergroups Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: how about telegram channel
On Tue, 19 Jul 2022 21:01:22 +0200, Bartosz Fenski wrote: >I'm tired of keeping VPS just to have IRC client and to be honest I >think modern solutions like Telegram are simply easier and much more >practical nowadays. It would also be simply easier and much more practical nowadays to ship an official installer that allows installation on modern hardware without hiding our head away in "we're fully free, but sadly we dont run on modern hardware unless you ditch that and use those unofficial images" That being said, I'll consider using a non-free chat service once we start shipping needed firmware on official media. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
adduser default for sgid home directories (was: Seeking consensus for some changes in adduser)
Back in March, I wrote in , https://lists.debian.org/debian-devel/2022/03/msg00304.html: > My post-discussion answer to question (1c) is yes, but I am still open > for arguments. If noone convinces me, the default for DIR_MODE will be > changed to 2700 (see (4) below). > > (...) > > A setgid bit on a non-group-readable directory might seem strange > though. Are there arguments against doing so aside from the ugly "S" in > ls output? We implemented that change last week, and promptly a bug report (#1014901) appeared, giving what we consider good arguments to change this back to 0700. Here is what the adduser team considers possible documentation for this, and we itend to include this in NEWS.Debian as a rationale for the change. Please comment. Suggested Documentation Text Follows: In adduser 3.122, we implemented code that allows setting the default for the mode bits of the home directory of a newly created system user independently of the mode bits of the home directory of a newly created non-system user (SYS_DIR_MODE vs DIR_MODE). This was in part done to finally solve #643559, which requested setting the sgid bit for the home directory of a non-system user by default, in order to ease setting access permissions of shared workspaces in multi-user systems. This default has oscillated back in forth in adduser multiple times since the 1990ies, because both ways to set this bit by default have advantages and disadvantages. After a preliminary request for comment (see https://lists.debian.org/debian-devel/2022/03/msg00098.html), the default value for DIR_MODE was changed to 2700 in adduser 3.122 (July 2022). Sadly, though the technical reasoning for NOT setting the bit have largely not survived the last two decades, here remain some use cases impacted by the change which we were not fully aware of. Promptly, #1014901 was filed, requesting that DIR_MODE be changed to 0700, effectively causing home directories of non-system users to be created without the sgid bit. The biggest point in the reasoning is that having the sgid bit set will need special measures to keep the home directory's group ownership from propagating to file system images, chroots, and archives, causing wrong file ownership/permissions in those entities, which in turn might propagate to different systems and cause security-related effects there. The bug report gives instructions to reproduce the behavior. System administrators who run multi-user environments which require shared workspaces have tools at their disposal to change the default behavior as their individual needs require, and likely are aware of how to work around any issues that arise as part of that configuration; it is also very possible that such systems may be managed using configuration management software. In an age of general purpose use on one end, and single purpose containers on the other, this is unlikely to be the majority of newly installed systems. So what remains is the decision to provide a sane default for a system that is installed by an end-user, who may not understand or be aware of this setting at all, but who still might use Internet HOW-TOs to build chroots, images or archives, inadvertently causing security issues on third-party systems. The clear and unsurprising solution is to leave the sgid bit for newly created users off by default. This is also important to keep the support effort for other packages down. Users surprised by the behavior might file bugs against other packages, increasing the effort necessary to support those other packages. In adduser 3.123, DIR_MODE will be changeed to 0700, flipping the default for the sgid bit once again to the value we have had for the majority of Debian's existence period. With this change, Debian is re-joining ranks again with ALL other major Linux distributions, none of which setting the sgid bit on home directories to 1 (research done in July 2022). As the root user and its home directory is created by other means, this primarily affects the one user that can be created in the Installer before there is any possibility to configure adduser. Those users will now again have the sgid bit of the home directory set to 0. Again, system administrators have the tools and documentation to configure their systems as their individual requirements dictate (using DIR_MODE, and/or fixing those initial directories). As mode 0700 provides both the most secure, unsurprising default, and is in line with most other major distributions, the adduser team considers the matter to be settled; any further discussion should come prepared with rationale, support, convincing use cases and a significant public discussion period. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 160040
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Thu, 14 Jul 2022 12:54:52 +0100, Steve McIntyre wrote: >And I see you uploaded ~immediately - why even bother with an ITP? Is it proper procedure to upload without an ITP? -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: [adduser] default group for 'dynamically allocated system users'
On Wed, 06 Jul 2022 15:21:03 -0400, Matt Barry wrote: >On Mon, 2022-07-04 at 09:12 +0200, Marc Haber wrote: >> adduser has been putting newly created 'dynamically allocated system >> users' (adduser --system) into the nogroup group. It is also >> documented to do so. There is an ancient bug report complaining about >> this, and I think this is a valid complaint. However, >> /usr/share/doc/base-passwd/users-and-groups.txt.gz says that no files >> should ever be owned by nogroup, making adduser do the right thing in >> its current state. >> >> Can you come up with a better default for users created with adduser >> --system without requesting a dedicated group? > >One idea worth considering, imho, is what the reporter [0] suggests: >make --group the default for --system. I don't like that idea at all, it'll introduce an avalanche of new groups. That should be in the responsibility of the individual package maintainer. >Sysadmin hat, I can think of situations >where having a dedicated service group is useful (eg. giving r/o access >to logs). We do have the adm group for that. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#1014372: ITP: journal-brief -- Show interesting new systemd journal entries
Package: wnpp Severity: wishlist Owner: Marc Haber X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: journal-brief Version : 1.1.8 Upstream Author : Tim Waugh * URL : https://github.com/twaugh/journal-brief * License : GPL-2+ Programming Lang: Python Description : Show interesting new systemd journal entries This program can be used to show entries from the systemd journal with configurable, flexible filters. Cursor files are used to keep information about when journal-brief was run for the last time and starts from there. journal-brief can output to stdout or send via SMTP. . journal-brief can, for example, be used to send out e-mail after a systemd timer was run, imitating cron's behavior.
[adduser] populating users group even in a usergroups system?
Hi, /usr/share/doc/base-passwd/users-and-groups.txt.gz currently suggests that the 'users' group is only populated on a system without usergroups. This would make the users group empty when adduser changes to having usergroups on by default. I am now wondering whether a new non-system user should end up in the users group automatically even if it has its own group created, making adduser's behavior regarding the users group independent of whether usergroups are used or not. What do you think? Greetings Marc P.S.. If adduser gets changed, I will file a bug against base-passwd to have the docs updated as well, of course -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[adduser] default group for 'dynamically allocated system users'
Hi, adduser has been putting newly created 'dynamically allocated system users' (adduser --system) into the nogroup group. It is also documented to do so. There is an ancient bug report complaining about this, and I think this is a valid complaint. However, /usr/share/doc/base-passwd/users-and-groups.txt.gz says that no files should ever be owned by nogroup, making adduser do the right thing in its current state. Can you come up with a better default for users created with adduser --system without requesting a dedicated group? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Firmware - what are we going to do about it?
On Wed, 1 Jun 2022 15:21:01 +, "Andrew M.A. Cater" wrote: >Basic tasks include networking - many IBM and Dell servers use(d) Broadcom >chipsets which wouldn't work without a non-free driver. Been caught out like >that installing in a data centre: can't get networking to work to get the >drivers I need for the network card. PXE boot will work and load a kernel and a doctored initrd that contains the non-free firmware. Been there, done that, for thousands of machines. It would be so nice if Debian would offer such an initrd out of the box. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Firmware - what are we going to do about it?
On Wed, 1 Jun 2022 09:41:35 +0300, Hakan Bay?nd?r wrote: >As a person who's handling a lot of servers, I can tell that most high >performance hardware is running either load-on-boot (generally ethernet >and other network cards) or persistent (generally storage and RAID >contollers) non-free firmware blobs. > >First category can perform basic tasks without firmware, but servers >being servers, this low performance mode is undesirable barring >light-load servers which is both a minority and a contradiction to the >word server in my profession. A machine that can boot and install debian without needing the firmware blob is already one step better than a machine that needs an install medium with firmware. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Project Improvements
On Wed, 25 May 2022 20:21:03 +0200, David Kalnischkies wrote: >apt actually marks dependencies >of packages in section metapackages as manually installed if the >metapackage is removed due to the removal of one of its dependencies >– but doesn't if you decide to remove the metapackage explicitly. That sounds nice and it's probably good to avoid accidental mass removals, but it makes the "manual" mark kind of a misnomer. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: shim-signed (was: Firmware - what are we going to do about it?)
On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre wrote: >We don't have good docs around this in general (hey, it's security >software - it's against the law to write good and complete docs!), but >I've certainly discussed this with a few folks over the years. It would be great to have that written down somewhere to tell poeple what they're actually doing. >Alternatively, people can build replacement shim-signed packages using >their own root of trust if desired. If we had a large enough number of >users wanting a different root of trust, we could even offer our own >different shim-signed package to match. I would probably prefer to have grub an/or the kernel signed, avoiding additional code, but maybe having some explanation would convince me that the shim actually improves things additionally to adding complexity. >Better than that, our shim-signed source package always double-checks >things here. At build time it removes the Microsoft signature and >compares that shim binary to the binary that we submitted for >signing. We would spot immediately if there was any code added. And if that check fails at build time, the Debian process refrains from putting a Debian signature on the deb and from uploading? Can the end user build the shim herself, remove the signature from the signed shim and compare the binary, preferably in a documented way? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: shim-signed (was: Firmware - what are we going to do about it?)
On Sat, 23 Apr 2022 13:54:59 +0200, Ansgar wrote: >On Sat, 2022-04-23 at 12:21 +0200, Marc Haber wrote: >> >Is the presence of shim-signed on the install media enough to make >> >people feel somehow contaminated? >> >> I think so, yes. Personally, I don't care too much but i can >> understand why some people might. > >Why? If only I knew. I myself don't feel to comfortable to rely on Microsoft being able to pull the plug on us any time. I don't know whether they can, but I imagine some kind of revocation mechanism being in place. And it's anther lay of indirection. While RFC compliant (1925, 6a) this introduces another possible attach vector since shim-signed might have to do its own check about the kernel to load. I do not know zilch about the shim, but this might be an issue for people. > Because it contains a third-party signature for which the private >key is not included in Debian? The same is true for signatures in >debian-archive-keyring, debian-keyring, ca-certificates, wireless- >regdb, and many other packages. A running system doesn't rely on any of those. >If we were to include more signatures in binary packages (e.g., a >signed manifest listing files (with hashes) shipped by the package, >signed executables, an embedded signature for the .deb itself), would >that be a problem? > >We do include signatures for source packages (*.dsc and also for >upstream tarballs) as well. I would LOVE to have an easier possibility to check the actual uploader's signature for anything in the archive short of squatting on every changes file ever visible. >> We can compile shim-signed and compare the signed code with our own >> object code, can't we? That we we would only have to worry about the >> validity and benignness of the signature and not worry about having >> undocumented functionality in the signed code. > >Debian's buildds build shim (binary package: shim-unsigned); the binary >generated by Debian is then signed by Microsoft's key. And we have a mechanism to check whether the code is actually the same? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
shim-signed (was: Firmware - what are we going to do about it?)
On Fri, 22 Apr 2022 11:16:42 +0200, Philip Hands wrote: >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. Excuse me for asking a user question on -devel, but do we have any docs where someone explains how much a security trade off is shim-signed relativ to the optimum? I think that using shim-signed is surely worse than a directly signed kernel, but I don't know whether I can tell my system (or shim-signed?) to accept MY or Debian's signed kernel without the Microsoft intermediate signature, and whether this is any more secure than running an encrypted system without secure boot at all. Do we have docs for that? >Is the presence of shim-signed on the install media enough to make >people feel somehow contaminated? I think so, yes. Personally, I don't care too much but i can understand why some people might. >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? We can compile shim-signed and compare the signed code with our own object code, can't we? That we we would only have to worry about the validity and benignness of the signature and not worry about having undocumented functionality in the signed code. >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. Those are the people who use Ubuntu without even trying Debian because somebody told them that Debian is SO hard to install. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Firmware - what are we going to do about it?
On Thu, 21 Apr 2022 10:12:19 -0700, Russ Allbery wrote: >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've spent >frustrated hours trying to follow the documentation and doing things that >look right only to have the installer say that there's no firmware visible >without any clue as to how to debug the errors. Every time I have tried >this, I have eventually given up and found the non-free images, which just >worked. Amen. I know one installation with a five digit number of Debian systems that uses a hacked installer with the Kernel from CentOS because that one just works. I have talked to the guy who did that operation (one of the most competent IT people I know) and he said nearly the same as Russ said. >If this is going to be the solution, it has to be WAY easier to do. Yes, absolutely. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Keep both images but stop pretending no-free is unofficial
On Tue, 19 Apr 2022 08:21:10 -0600, Sam Hartman wrote: >One valuable suggestion was to make sure users could easily select >freedom if that's what they wanted. >So I think a free installation image is important. Would that not be possible by having an image WITH firmware and an installer asking whether the user wants a free or a usable system? Greetings Marc -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
ly unacceptable names. For system accounts, the allowed chars are an optional leading underscore, lower case letters, numbers, underscores, dashes. This means that packages using names like Debian-exim or Foo will need to keep their override-option active like today, but new packages using a system account like _apt can use that name without having to override our checks. We still have packages using the dot syntax in chown shell scripts. There is a new Lintian check to warn for that now, but I don't think that Debian is ready today to allow dots in user names right now. Local administrators who need a more permissive regexp for their local users might change NAME_REGEX and take some responsibility to file bugs against packages that break with that relaxed setting, but in the default user accounts will still have to restrain themselves to ASCII letters (lower and upper case), numbers, underscores, dashes, with leading underscores not being allowed by the default regexp. > (3) > #625758 > --disabled-password just does not set a password for the newly created > account (resulting in '*' in shadow) while --disabled-login places a '!' > in shadow. On modern systems with PAM, both variants seem to be > identical, allowing login via ssh. Aside from the documentation needing > change to document reality, should we introduce a --no-set-password > option and deprecate the two older options (to be removed in trixie+2)? --disabled-password will result in a "*" in /etc/shadow, effectively making it impossible to use any password based authentication. This will also suppress the setting of a password during creation of a user account, which we currently do by just calling passwd and leaving the work to the subprocess. --disabled-login will set the login shell to /usr/sbin/nologin, disabling the account for most usages. This needs changes to the documentation, we will do that and write an appropriate NEWS.Debian entry as this may be relevant. No other changes to options are planned in this regard. Adduser does not support changing the password of an account that already exists, there are no plans to change this. > (4) > #979385 #248130 > The default for SETGID_HOME is =no, with a comment from the last century > that states that the default was changed from yes to no because of "bad > side effects" this had. Does anybody have an idea which bad side effects > could be meant by that, and what would we possibly break by changing the > default to "yes"? I do plan to set the default for DIR_MODE to have the setgid set and to change SETGID_HOME to yes. SETGID_HOME is redundant if DIR_MODE exists, so this is going to be deprecated, removed from the docs in trixie and from the code in trixie+1. I think it is safe to assume that the "bad side effects" mentioned in the configuration file are historic and non longer relevant here. > (5) > #678615 > should all newly created non-system users be added to the users group > even on a system with userprivate groups (as it is the default)? > (6) > #849265, > https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2017-January/032300.html > Should we really empty out the extra_groups list default? This can be answered together, I plan to change EXTRA_GROUPS to just contain "users" in the future. I am trying this setting on my personal systems now. What was not in the primary discussion: deluser will grow a --lock option that will replace a user's shell with /usr/bin/nologin. There will be a configuration option chanding deluser's default behavior to not actually delete a --system account but lock it. That way, a package can call deluser --lock in postrm for remove, and straight deluser in postrm for purge, while leaving the final decision what should happen with system accounts on purge to the local administrator. The default for said configuration option will depend on the outcome of #1006912 which tries to change/adapt policy in this regard. Thank you for your time. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Q: systemd-timer vs cron
On Mon, 14 Mar 2022 09:29:56 +0800, Paul Wise wrote: >The cron feature of sending the output via email by default isn't >possible to get easily with systemd timers or systemd-cron, unless you >modify every single timer to manually send email or use systemd-cron >and have every single timer fail. This is something that has been hindering migrations since I was young: People identify one feature that is going away as vitally important to them and use that to reject the movement, even if it's an advance in sum. See NAT or DHCP for IPv6. >Having everything in one file makes them more convenient to edit. Same ;-) >Being able to implicitly share environment variables between groups of >crontab lines is more convenient. Since Lennart seems to have decided not to get rid of the EnvironmentFile setting, that can be replaced. >Figuring out if there native systemd equivalents for features I've >implemented manually, such as the lock and sleep times to ensure system >load isn't high due to running everything at once or disabling jobs >when the network isn't online. I think that the equivalent of cron.daily in systemd timers would make excessive use of start point randomization, that is going to take care of load spikes. Additionally, it will take care of load spikes in VM environments (see 07:35 when all machines begin their cron.daily simultaneously). Migrating to more randomized times of daily runs is also going to expose the case where certain cron jobs depend on each other and only work if they're executed in exact order. >Spending the time to migrate everything. Yes, that's a point. Would it be an alternative to spend time on cron and cronie patching and packaging? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Q: systemd-timer vs cron
On Sun, 13 Mar 2022 18:02:55 +0100, Christian Kastner wrote: >On 2022-03-13 11:06, Marc Haber wrote: >> The anti-systemd faction in Debian is cordially invited to step in, >> bring cron and cronie up to shape, before asking the rest of the >> Distribution to stick with essential system software that has been >> unmaintained for years. > >I don't think that's a very constructive line of argument. As a former >maintainer, it was evident that user crontabs (crontab -e) are still >very popular, as are some other perhaps niche features, and I've never >had the impression that anti-systemd has anything to do with it. That was not my intention to say. And I didn't want to put your maintenance work in a bad light. You had quite ambitioned plans and I am sad that it didn't work out. And, given our personpower problem regarding core packages, your plans are unlikely to go forward any time soon with both cron and cronie being more or less maintainerless. Not being a systemd fanboi myself, for many things I prefer having mechanisms outside of systemd, but if an alternative is unlikely to move forward any time soon, I'd seriously consider migrating to something that IS moving forward, and that is systemd timers. >And in all fairness, I did invest a lot of time maintaining it over the >years before I stepped down recently. I spent hundreds of hours alone on >converting our fork of Vixie cron from source format 1.0 to 3.0 (the >cumulative 1.0 diff spanned more than two decades of changes) so that >our fork can more easily be compared and merged with other cron forks, >such as cronie. That was very good work and I am sad to see that this work is unlikely to be done soon. >I completed that task a while ago, but then lost all motivation to >continue further. The cron daemons all originate from the early 90s. >systemd timers, being newer, just seem like a much cleaner >implementation, and thus the way forward to me. I could no longer muster >the time or energy to work on something I wasn't happy with, so I >stepped down. I fully understand. >In my opinion, the way forward for cron would be for someone to adopt >cronie, carry over any Debian patches not already included or equivalent >(there aren't too many, last time I checked), and to make cronie the new >default cron daemon. That would be very good. Sadly I am not in a position to do that myself because I lack the C skills. i surly hope that someone steps in. Thank you for caring about cron and cronie! Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Sun, 13 Mar 2022 20:52:47 -0600, Sam Hartman wrote: >Let me try asking something more reasonable. >If you end up tightening down world readableness, let me know so I can >reject the umask patch, because I suspect if your decision to tighten >down being world readable sticks, the 15 year old usergroups decision >would need to be revalidated by someone who cared. Wouldnt the umask patch be even more useful if we tightened down the directory permissions? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Q: systemd-timer vs cron
On Sun, 13 Mar 2022 08:47:27 +0100, Christian Kastner wrote: >Unless cron finds a new maintainer (#984736), I don't think either of >these are going to happen. This looks like we all should migrate over to systemd timers as soon as possible for everything, leaving the burden of keeping cron alive to those systemd-free distributions. The anti-systemd faction in Debian is cordially invited to step in, bring cron and cronie up to shape, before asking the rest of the Distribution to stick with essential system software that has been unmaintained for years. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Sat, 12 Mar 2022 14:41:35 -0500, Michael Stone wrote: >On Fri, Mar 11, 2022 at 10:16:24PM +0100, Marc Haber wrote: >>[^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] is found 829 >>times in Debian, mostly in docs and comments, but also in a few live >>scripts. I think that we still have some way to go until we get rid of >>the dot notation in chown calls. > >It also has to be a variable; if it's "root.root" or such, it doesn't >matter. It matters if coreutils will at some time remove the dot notation, making chown root.root an error. And I surely hope that this is the end of the road we're progressing on. >And remember, there are existing real-world debian systems that have >users with dots (regardless of local adduser policy; think ldap/ad for >example) so these are already issues that either need to be fixed or >don't really matter. Yes, they need to be fixed, but it's a different can of beer if we cannot say "hey, you changed our default, so you get to keep the pieces of what got broken" but have to say "oops". Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 17:38:20 -0800, Noah Meyerhans wrote: >+1 to --disabled-login setting the shell to /usr/sbin/nologin with >documentation being updated to reflect this. I'd suggest a default >behavior of a password of '*', with the ability to override it and >prompt for a real password with a "--set-password". Although honestly, >I also wouldn't be opposed to requiring an extra step of calling >'usermod' to set a password for a disabled account. It's sort of a >special case, and not one that has to be explicitly handled by adduser. Noted. I will post a summary at the beginning of the new week. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Fri, 11 Mar 2022 10:45:50 -0500, Michael Stone wrote: >I don't have a really strong preference either way. Maybe carry a patch >until just before freeze to bubble stuff up during testing? Maybe allow >an environment variable to override (either way?) to facilitate testing? >The problem is that the systems most likely to blow up (because they're >using ancient scripts) are also really unlikely to suddenly start using >dot usernames, so breaking them for the sake of correctness on other >systems seems gratuitous. If there isn't already, maybe some kind of >lintian script check (though that seems probably challenging for static >analysis)? In the end, there are already so many ways to shoot yourself >in the foot with shell scripts if you don't follow all the disorganized >rules every single time that letting this be the reason to disallow dot >usernames seems extreme. [^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] is found 829 times in Debian, mostly in docs and comments, but also in a few live scripts. I think that we still have some way to go until we get rid of the dot notation in chown calls. This would be a nice idea for an MBF. Sadly I do not have the time to do that. I have filed a wishlist bug for a lintian check. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: adduser: disabling passwords, disabling logins
On Thu, 10 Mar 2022 21:25:38 +, Simon McVittie wrote: > usermod: unlocking the user's password would result in a passwordless > account. > You should set a password with usermod -p to unlock this user's password. So I can assume that usermod -p will also unlock a previously locked account? I hate the inconsistent terminology that we have here. Thanks for testing. Greetings Marc -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: systemd-sysusers [Re: Seeking consensus for some changes in adduser]
On Thu, 10 Mar 2022 20:59:50 +0100, Michael Biebl wrote: >have you considered a more declarative approach as provided by >systemd-sysusers (8)? No. This thread is about evolving adduser. Not getting rid of it. 514 packages in Debian match "adduser.*--system". Feel free to offer a declarative thing and encourage maintainers to migrate. adduser is going to continue to offer a stable interface for existing packages for the time being. It has been adduser's goal for 20 years now to be as declarative as possible in a maintainer script by doing everything necessary, just requiring the package to have one line in the right place in the script. Greetings Marc P.S.: I got involved with adduser 20 years ago because the then debhelper maintainer brushed off my suggestion to have a dh call for creating system users. Back then, this approach was as declarative as it could get. -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 13:17:26 -0800, Steve Langasek wrote: >On Thu, Mar 10, 2022 at 06:37:58AM +0100, Marc Haber wrote: >> On Thu, 10 Mar 2022 00:04:38 +0100, Ansgar wrote: >> >On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote: >> >> Those are actually unrelated--the big reason for the more permissive >> >> umask is to allow people to seamlessly work with other people in a >> >> group, especially within setgid shared directories. Those shared >> >> directories can be anywhere, and are likely *not* in a single user's >> >> home. > >> >Setting a default ACL on project directories seems a technical better >> >solution for this problem. It would only affect permissions of files >> >that should intentionally be group-readable, not all files created >> >anywhere. > >> Are we using ACLs bei Default already in other places of the Debian >> system? > >We are using filesystem capabilities; and as far as I'm aware we have no >filesystems that support fscaps extended attributes but NOT acls, nor am I >aware of any archive formats that would preserve fscaps without also >preserving acls. Is this usage in a place that a user would consciously have to interface with? I still raise my eyebrow when I see that "+" somewhere. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 00:01:36 +, Seth Arnold wrote: >On Tue, Mar 08, 2022 at 05:49:04PM +0100, Marc Haber wrote: >> (2) >> #774046 #520037 >> Which special characters should we allow for account names? > >Please consider the leading character separately from the rest of the >characters: > >- leading digits sometimes causes programs to parse a 'username' as an > 'user id' instead; you can see some of this here: > https://github.com/systemd/systemd/issues/6237 > I know I've seen more instances of this over the years. > >- leading dash may cause the username to be treated as command line > options in some programs. I've lost references to this happening. Should those two restrictions apply for both system and user accounts? Should they be overrideable? >While you can argue these are bugs in the programs involved, they do >happen in the wild. Thus, I'd like to suggest that the regex be more >restrictive for the first character. Noted. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Wed, 09 Mar 2022 21:34:33 +0100, Pierre-Elliott Bécue wrote: >Considering many have replied, I'll stick to that one: >Marc Haber wrote on 08/03/2022 at 17:49:04+0100: >> (3) >> #625758 >> --disabled-password just does not set a password for the newly created >> account (resulting in '*' in shadow) while --disabled-login places a '!' >> in shadow. On modern systems with PAM, both variants seem to be >> identical, allowing login via ssh. Aside from the documentation needing >> change to document reality, should we introduce a --no-set-password >> option and deprecate the two older options (to be removed in trixie+2)? > >How about --disabled-login => shell is set to /usr/sbin/nologin ? I have noted that as one of the options for my summary. I assume that in that case, the password should still be * to avoid creating an active unlocked account with empty password? Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Wed, 9 Mar 2022 17:29:01 -0500, Michael Stone wrote: >On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote: >>I don't think it makes sense to move toward 0700 home directories and to >>loosen the umask for usergroups. > >Those are actually unrelated--the big reason for the more permissive >umask is to allow people to seamlessly work with other people in a >group, especially within setgid shared directories. Those shared >directories can be anywhere, and are likely *not* in a single user's >home. Hence, no change needed in adduser? Or is that an argument for having DIR_MODE=0700 in default? >This was changed in coreutils to be posix-compliant more than 20 years >ago. The spec is that chown accepts user:group syntax, and chown will >always first attempt to split on ":". If there is no :, chown will try to >resolve the whole argument as a username (that is, regardless of whether >there's a "."). If the username isn't resolvable *and* it contains a >".", it will try to split on the first "." and use the left side as the >username and the right side as the group. So *only if* someone attempts >to use a dot-containing username in chown without a : and the >dot-containing username is invalid, then it might be interpreted as a >user.group spec. >Now, if someone is trying to actually use user.group >syntax rather than the user:group syntax that's been standard for 20+ >years, that will definitely break in the presence of dot-containing >usernames. ... but just in the case that the same string exists both as the last component of a dot-containing user name AND as a group name. All other cases are defined. How would the spec listed above behave for user names with more than one dot? > Given how common such usernames are on other systems, I'd >expect the breakage to be minimal by now, and a bug in anything still >using that syntax. We could make coreutils print a deprecation warning, >but that's never really been useful in the past; probably better to just >error out any time a . is used for something other than a valid username >and drop the 20+ year old compatability code. Do you want a coreutils bug to error out in the case of user.group notation in chown? I guess it's due time. Would we go alone in Debian or would you prefer that we try convincing upstream to finally go that way? I am not convinced that Debian should derive from standard behavior here, but you have the coreutils hat on and I would support either decision. And then we'd have to decide whether adduser may allow dot-containing user names before coreutils made this change. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: adduser: disabling passwords, disabling logins
On Thu, 10 Mar 2022 13:57:13 +0200, Wouter Verhelst wrote: >On Wed, Mar 09, 2022 at 09:00:22PM +0100, Marc Haber wrote: >> On Tue, 8 Mar 2022 18:40:11 +, Simon McVittie >> >--disabled-login: the new account has an empty password but is "locked"; >> >so password authentication will fail, but "unlocking" the account will >> >result in login being accepted with a blank password (subject to other >> >policies like ssh PermitEmptyPasswords and PAM nullok) >> >> that way, --disabled-login doesnt sound desireable at all, it would >> violate the principle of least surprise at least for me. I'd have >> expected (and always believed) that a password of ! will also prevent >> ssh-key logins from happening. > >I don't see how that follows from Simon's statement? AIUI, he's saying >that that is true *until" you unlock the account (which essentially >means dropping the "!" from the passwd file). > >Am I misreading something here? I have re-read Simon's words and still have the interpretation that unlocking an account that has been created with -disabled-login will allow login without password, making the account completely open. Maybe some native speaker might want to bring light into this by choosing different words for what Simon wrote. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 11:19:56 +0100, Harald Dunkel wrote: >This is another trap: /etc/login.defs seems to define some ranges for >"system" uids and gids. They are commented out by default, nevertheless >they imply some configurability. Are changes in login.defs supposed to >be respected by all packages, including passwd (useradd) and adduser? fwiw, adduser has never been interested in this configuration. the login.defs(5) manpage says that it is the "shadow password suite configuration". I am not sure whether adduser should honor that configuration. At least both configurations are in sync to each other. Would it make sense that adduser reads login.defs if the respective setting is not overridden in adduser.conf? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 09:28:24 +, Simon McVittie wrote: >On Thu, 10 Mar 2022 at 06:37:58 +0100, Marc Haber wrote: >> Are we using ACLs [by] Default already in other places of the Debian >> system? > >For user-facing purposes I don't think so (although they're available to >anyone who wants to set them), I would rather not be the first one doing so. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Wed, 9 Mar 2022 14:35:52 -0600, Richard Laager wrote: >If the admin can change the default DIR_MODE that applies to system user >home directories, then any postinst script doing `adduser --system` >needs to also explicitly chmod its home directory if it needs anything >more permissive than 700 or more restrictive than 755. This is true >today and remains true whether or not the default DIR_MODE is changed. Anything that NEEDS to be written in postinst scripts is bad. I'd rather implement a SYSTEM_DIR_MODE setting that applies to directories created during creation of a --system user. Would that help with the issue? >> How would chown handle the dot case intelligently? > >Something along the lines of see if the user exists. Michael Stone has elaborated on that topic and told us how chown already behaves. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 00:04:38 +0100, Ansgar wrote: >On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote: >> Those are actually unrelated--the big reason for the more permissive >> umask is to allow people to seamlessly work with other people in a >> group, especially within setgid shared directories. Those shared >> directories can be anywhere, and are likely *not* in a single user's >> home. > >Setting a default ACL on project directories seems a technical better >solution for this problem. It would only affect permissions of files >that should intentionally be group-readable, not all files created >anywhere. Are we using ACLs bei Default already in other places of the Debian system? Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: adduser: disabling passwords, disabling logins
On Tue, 8 Mar 2022 18:40:11 +, Simon McVittie wrote: >On Tue, 08 Mar 2022 at 17:49:04 +0100, Marc Haber wrote: >> (3) >> #625758 >> --disabled-password just does not set a password for the newly created >> account (resulting in '*' in shadow) while --disabled-login places a '!' >> in shadow. On modern systems with PAM, both variants seem to be >> identical, allowing login via ssh. > >I assume you mean: allowing login via ssh if other steps have been taken >to allow it, like creating and populating ~/.ssh/authorized_keys? Yes, right. >This ties in with the suggestion that system accounts should be "locked" >(usermod -L -e 1) when the package that owns them is removed. Yes. >usermod -L >edits the crypted password in /etc/shadow to prevent login, by prepending >'!', which is not a possible crypt(3) output: so it seems the distinction >between these options is something like: > >--disabled-password: the new account doesn't have a valid password, so >password authentication will always fail > >--disabled-login: the new account has an empty password but is "locked"; >so password authentication will fail, but "unlocking" the account will >result in login being accepted with a blank password (subject to other >policies like ssh PermitEmptyPasswords and PAM nullok) that way, --disabled-login doesnt sound desireable at all, it would violate the principle of least surprise at least for me. I'd have expected (and always believed) that a password of ! will also prevent ssh-key logins from happening. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Wed, 9 Mar 2022 14:10:04 +0100, Harald Dunkel wrote: >On 2022-03-08 17:49:04, Marc Haber wrote: >> (1a) would it be necessary to handle --system accounts differently? I >> think yes. > >I think it would be helpful to define "system account" and "normal user". >Neither adduser(8) nor useradd(8) provide a sufficient definition, >especially wrt the existing network directory services (LDAP, AD, etc). In adduser, a --system (sic!) account is one that is created using the --system option. Basically, the biggest difference is that its UID is allocated from a different UID range, see policy 9.2.2. I just see that policy says "dynamically allocated system users and groups", while it refers to uid 1000-5 as "dynamically alllocated user accounts". So I am happy that my (and adduser's) notion of system and user accounts actually matches policy, but I agree that we need to be more explicit in adduser, probably referring to Policy in the adduser docs. >Is a "system user" supposed to be a local account, defined in /etc/passwd >only? That is not defined in policy, but it should. The current policy editing process is based on a proponent suggesting an exact wording with the policy editors just giving advice. Since I don't have a strong position in this regard, I'm out here. >Related question: How are naming collisions between local entries and >the entries in a network directory service supposed to be handled? >Something like > > passwd: files sss > >in /etc/nsswitch.conf is not helpful, if a postinst script fails to >create a local account due to the entry it has found in freeipa, for >example. Not to mention that such a service might fail at boot time, >if the directory service is not available (yet). That is beyond adduser's scope. We're (as the adduser team) usually weasel out of that topic by saying that a system refering to a directory service is run by skilled staff, and we expect those people to do their job. It's a small team, adduser has been in limbo for years, so we need to concentrate on the traps that a novice or unexperiences user might fall into while relying on skilled users to work around the issues that we haven't found the time to fix. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager wrote: >On 3/8/22 10:49, Marc Haber wrote: >> (1) >> #202943, #202944, #398793, #442627, #782001 >> The bug reporters are requesting the default for DIR_MODE to be changed >> from 0755 to 0700, making home directories readable for the user only. >> Policy 10.9 states that directories should be 0755, but the policy >> editors probably didn't have user home directories in mind when they >> wrote that. > >As a data point, Ubuntu moved to 750 a year ago: >https://ubuntu.com/blog/private-home-directories-for-ubuntu-21-04 I still see Ubuntu as targeted heavily at end-user systems used by beginners. I don't think that all decisions that are good for Ubuntu are good for Debian as well. >> (1a) would it be necessary to handle --system accounts differently? I >> think yes. > (1b) should we stay with 0755 for --system accounts? > >I don't see why system accounts need to be different. avahi-daemon has /var/run/avahi-daemon as its home directory and places its socket there. I'd guess that having this directory not accessible for the world will kind of influence the usability of the daemon. We have many packages that are configured like that. dnsmask even has /var/lib/misc as home, which is not even owned by the account, so setting that one to 0750 would probably be even more destructive. No, that's trying too much. >> (1c) does a change to 0700 for user accounts make sense? > >Yes. Can we get consensus on that? >> (1d) should it be 0751 (#398793)? > >Pro: That helps ~/public_html. > >Con: That seems like a trap for non-expert users. It _feels_ like other >people can't get at things, but they actually can, if they know the next >directory down. I (and probably everyone reading this list) understands >the "1" in 751, but do end users? Point. >> (1e) how about ~/public_html that would break with 0750? > >As a comment on the bug mentioned, public_html not a default thing. >Changing DIR_MODE and/or ACLs are also options for those who want a >~/public_html concept. A webserver serving userdirs should be in the hands of a competent admin, right? >> All those bugs referenced have more or less heated exchanges ranging >> from "it's fine" to "we should issue a DSA ASAP", most of them a decade >> old, so the times might have changed since then. Please note that the >> DIR_MODE _IS_ configurable in adduser, we're just discussing the >> default (which also applies for home directories created while still >> inside the Installer before a local admin can properly configure >> adduser). > >I think there is merit to defaulting to the most secure (but still >reasonable) option, and letting people loosen it if desired. Point. >> (2) >> #774046 #520037 >> Which special characters should we allow for account names? >> >> People demand being able to use a dot (which might break scripts using >> chown) and non-ASCII national characters in account names. The regex >> used to verify non-system accounts is configurable, so the policy can be >> locally relaxed at run-time. >> >> For system-accounts, I'd like to stick to ASCII letters, numbers, >> underscores. > >I support dashes, as was already discussed. That's already in use. > >I think the idea of dot in a username is perfectly reasonable on its >own. For some people this is very desirable. My wife, for example, uses >a dot in her email username as her first name plus my-now-her last >initial makes a word that is awkward. (This sort of problem is not >uncommon in usernames, especially at companies that make them via some >algorithm.) > >I always use colon for chown, which is what is documented, but I'm aware >it takes dot too. Is there any code in chown to handle the dot case >intelligently? How would chown handle the dot case intelligently? At the moment, the chown manpage doesn't contain the words "dot" or "period", but chown root.root some-file will do the same like chown root:root some-file, changing user and group. >Non-ASCII does feel a little concerning to me (since those code paths >won't be exercised very often). I think they would in non-latin countries. >But to recognize my bias, I have no need for a non-ASCII username. I'd >probably feel quite differently if my name wasn't correctly >representable in ASCII. Put differently, if usernames were currently >required to be Han or Cyrillic characters, I'd certainly be up in arms >asking for Latin character support. Yes, that's my feeling as well. otoh, adduser can already be configured to be more relaxed for user accounts, so you can have an all-cyrillic user name already today, adduse
Re: Seeking consensus for some changes in adduser
On Tue, 8 Mar 2022 19:06:57 -0500, Timothy M Butterworth wrote: >On Tue, Mar 8, 2022 at 6:18 PM Richard Laager wrote: >Please add support for "." so we can use first.last names as user >names. Other Linux's are already doing this so it should not break >anything. Adduser can already be configured to allow that via a documented interface. We're talking about the default here. The only point where an account might be created before that configuration possibility becomes available is the Installer. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Wed, 9 Mar 2022 00:12:25 +0200, Adrian Bunk wrote: >On Tue, Mar 08, 2022 at 05:49:04PM +0100, Marc Haber wrote: >>... >> (2) >> #774046 #520037 >> Which special characters should we allow for account names? >> >> People demand being able to use a dot (which might break scripts using >> chown) and non-ASCII national characters in account names. The regex >> used to verify non-system accounts is configurable, so the policy can be >> locally relaxed at run-time. >> >> For system-accounts, I'd like to stick to ASCII letters, numbers, >> underscores. >>... > >There is a DD with the login 93sam, and this is already outside of >what systemd accepts.[1] ... as "User" option in system files. Not going to begin another systemd flame war today. Bugs like that look like they'll probably only relevant for accounts that services run under. >Non-ASCII characters in account names sound like a lot of breakage >and CVEs to me. Agreed, but people want that. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Tue, 08 Mar 2022 20:48:46 +0100, Ansgar wrote: >On Tue, 2022-03-08 at 12:29 -0700, Sam Hartman wrote: >> > > > > >> Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 >> >> According to the history of that patch, we have some old consensus to >> move toward usergroups and a default umask of 0002 (except for root >> which gets 0022). > >On systems that don't use usergroups for all/some users, doesn't this >change make all files writable by other users by default? That would >seem like a very unsecure change on upgrades (or as a default). Maybe we need to adapt that patch to only set umask to 002 if the user's primary group is identically named. >(Though I think the current world-readable by default is already quite >bad. It seems like a unsafe choice on both single-user and multi-user >systems...) It surely references an administration style that sadly does not fit these days. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Seeking consensus for some changes in adduser
On Tue, 08 Mar 2022 12:29:43 -0700, Sam Hartman wrote: >Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 As far as I understand, that's a PR against pam setting umask.to 002 on login, 022 for root. Especially the bug reports referenced there bring me directly and deeply into Debian-Ubuntu politics which is a significant drain for me. >According to the history of that patch, we have some old consensus to >move toward usergroups and a default umask of 0002 (except for root >which gets 0022). > >I was trusting the analysis in that merge request and assuming we >actually did have such a consensus. I am not aware of that. If we have consensus, then all the better. >But I'd ask you to look into the history of usergroups in Debian as part >of your decision process. Where would I read up on that? I am not deeply enough in those political things to be able to judge whether a discussion from 15 years ago is still valid today. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: special characters in account names
On Tue, 8 Mar 2022 18:31:48 +, Simon McVittie wrote: >On Tue, 08 Mar 2022 at 17:49:04 +0100, Marc Haber wrote: >> (2) >> #774046 #520037 >> Which special characters should we allow for account names? >> >> For system-accounts, I'd like to stick to ASCII letters, numbers, >> underscores. > >ASCII letters, numbers, underscores and dashes (U+002D HYPHEN-MINUS), >I hope? Lots of system accounts already use dashes, notably www-data >in the base-passwd set. Of course. I would break a lot of my own packages otherwise ;-) Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Seeking consensus for some changes in adduser
Hi, you might have noticed that the adduser package has gained some momentum in the last week, thanks to a new volunteer helper, Jason Franklin, who has taken care of the actual code. I am acting as advisor and Debian specialist in this team and am currently doing bug triage. For the people who don't know about the program, adduser is kind of a wrapper around useradd that is used in Debian to create local accounts. While it of course can also create "normal" user account, it has evolved in the last 20 years to kind of a policy layer that can be used from maintainer scripts to create package-related accounts, following Debian policy and avoiding bugs. adduser's defaults need careful choosing since there is a lot of breakage potential. I have some issues that I would like to solicit the opinion of my fellow DDs and to reach rough consensus about some changes that have been requested from Adduser in the BTS but I am reluctant to go through with on my own decision. (1) #202943, #202944, #398793, #442627, #782001 The bug reporters are requesting the default for DIR_MODE to be changed from 0755 to 0700, making home directories readable for the user only. Policy 10.9 states that directories should be 0755, but the policy editors probably didn't have user home directories in mind when they wrote that. (1a) would it be necessary to handle --system accounts differently? I think yes. (1b) should we stay with 0755 for --system accounts? (1c) does a change to 0700 for user accounts make sense? (1d) should it be 0751 (#398793)? (1e) how about ~/public_html that would break with 0750? All those bugs referenced have more or less heated exchanges ranging from "it's fine" to "we should issue a DSA ASAP", most of them a decade old, so the times might have changed since then. Please note that the DIR_MODE _IS_ configurable in adduser, we're just discussing the default (which also applies for home directories created while still inside the Installer before a local admin can properly configure adduser). (2) #774046 #520037 Which special characters should we allow for account names? People demand being able to use a dot (which might break scripts using chown) and non-ASCII national characters in account names. The regex used to verify non-system accounts is configurable, so the policy can be locally relaxed at run-time. For system-accounts, I'd like to stick to ASCII letters, numbers, underscores. (3) #625758 --disabled-password just does not set a password for the newly created account (resulting in '*' in shadow) while --disabled-login places a '!' in shadow. On modern systems with PAM, both variants seem to be identical, allowing login via ssh. Aside from the documentation needing change to document reality, should we introduce a --no-set-password option and deprecate the two older options (to be removed in trixie+2)? (4) #979385 #248130 The default for SETGID_HOME is =no, with a comment from the last century that states that the default was changed from yes to no because of "bad side effects" this had. Does anybody have an idea which bad side effects could be meant by that, and what would we possibly break by changing the default to "yes"? (5) #678615 should all newly created non-system users be added to the users group even on a system with userprivate groups (as it is the default)? (6) #849265, https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2017-January/032300.html Should we really empty out the extra_groups list default? Thanks for helping adduser being a better package! Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Getting in contact with the i386 porters
On Tue, 15 Feb 2022 13:41:22 +0100, Ansgar wrote: >The architecture requalification page for bookworm currently lists a >single porter for i386[1]. Maybe contact him directly? > > [1]: > https://salsa.debian.org/release-team/release.debian.org/-/blob/bb0660c80401eeacbe7063044a9a1b711dcc2303/www/bookworm/arch_spec.yaml#L108 That was a very helpful idea (and a very helpful porter). Things are going forward now. Thanks for helping. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Getting in contact with the i386 porters
Hi, I have a problem with sudo, Bug #1004894. sudo from unstable seems to not work on an AMD Geode LX processor. Unfortunately, I don't have any i386 systems left, there don't seem to be any public i386 porterboxes other than 64bit boxes running 32bit chroots, and the i386 port traditionally doesn't have a port-specific mailing list. i386@buildd.d.o was Cced two weeks ago without any reaction. How would I proceed from here? I suspect this to be a toolchain / buildd essue and feel myself being at a loss regarding this issue. Is the Geode LX supported by the i386 port in the first place? I see Kernel taint flags: TAINT_CPU_OUT_OF_SPEC in the logs, but also CONFIG_MGEODE_LX=y in Debian's i386 kernel. Please advise, thanks. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Do we need to hide packages in NEW queue
On Mon, 31 Jan 2022 10:07:32 +0100, Stephan Lachnit wrote: >On Sun, Jan 30, 2022 at 8:35 PM Russ Allbery wrote: >> I do think that the amount of effort that the project puts into this >> pre-screening is of sufficiently high magnitude that it would be worth >> paying a lawyer for a legal opinion about whether or not we need to do >> it. The savings to the project if we found out that we didn't, or that we >> could do something simpler and more easily automated, would be more than >> the cost of the legal opinion. > >Looking at the last financial numbers I found [1], we have at least >~750k USD we could use for this purpose. I don't really know how >expensive lawyers are, but I doubt that this would cost more than 10k. >Heck, we could even hire two lawyers without any significant financial >impact (maybe in the US and EU as I think these are probably the most >prominent areas for potential copyright lawsuits), even if it costs >50k. Even if a lawyer says A, it doesn't buy us anything if J Robert DD gets sued and the judge says B, or "not A". Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Cloud team plans for cloud-hosted mirrors
On Wed, 26 Jan 2022 15:27:53 +0100, Bastian Blank wrote: >On Wed, Jan 26, 2022 at 07:25:18AM +0100, Marc Haber wrote: >> Are the IP ranges of the Cloud Providers registered that badly that >> deb.debian.org wouldn't reliably point to the mirrors inside the >> provider's infrastructure? Or are the cloud providers' mirrors >> differnet from what we expect from a Debian mirror? > >I wonder, which mechanism would you propose to do so? I have no idea but I would expect that a GeoIP-similar mechanism would allow to point clients to a local mirror inside the vendor's cloud infrastructure. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Cloud team plans for cloud-hosted mirrors
On Tue, 25 Jan 2022 22:38:00 -0800, Ross Vandegrift wrote: >On Wed, Jan 26, 2022 at 07:25:18AM +0100, Marc Haber wrote: >> On Tue, 25 Jan 2022 21:47:49 -0800, Ross Vandegrift >> wrote: >> >The cloud team wants to make folks aware of a possible change to the cloud >> >images. The team plans to register a new domain, debian.cloud, for mirrors >> >inside of cloud provider infrastructure. For such mirrors, sources.list >> >will >> >look like: >> > deb http://.debian.cloud/debian/ bullseye main >> >> Are the IP ranges of the Cloud Providers registered that badly that >> deb.debian.org wouldn't reliably point to the mirrors inside the >> provider's infrastructure? Or are the cloud providers' mirrors >> differnet from what we expect from a Debian mirror? > >deb.debian.org is served from fastly and AWS CDNs - so it's outside of most >cloud provider's infrastructure. So it is not possible to hook arbitrary mirrors into deb.debian.org and we're dependent on Fastly and AWS here? I thought it was something more flexible. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Cloud team plans for cloud-hosted mirrors
On Tue, 25 Jan 2022 21:47:49 -0800, Ross Vandegrift wrote: >The cloud team wants to make folks aware of a possible change to the cloud >images. The team plans to register a new domain, debian.cloud, for mirrors >inside of cloud provider infrastructure. For such mirrors, sources.list will >look like: > deb http://.debian.cloud/debian/ bullseye main Are the IP ranges of the Cloud Providers registered that badly that deb.debian.org wouldn't reliably point to the mirrors inside the provider's infrastructure? Or are the cloud providers' mirrors differnet from what we expect from a Debian mirror? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: The future of src:ntp
On Tue, 18 Jan 2022 21:49:53 +0100, Michael Biebl wrote: >Fwiw, I'm with Marco here: If systemd-timesyncd (a simple SNTP client >which is enabled by default) doesn't fit your needs, chrony is a great >alternative. The Beef I have with chrony is that they just implemented the parts of the protocol that they wanted to. Most notably, ntp request packet type 6 is missing, making it impossible to remotely monitor a chrony server with the Monitoring Plugin check_ntp_peer. Who knows which crucial parts of the protocol they didn't bother to implement either? Greetings Marc -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Extending debspawn
Hallo, debspawn is extremely handy if one just wants a container to quickly try stuff or to build a package in a clean environment. I especially like that zero infrastructure is needed: We already have systemd and that's all whats needed to fire up an nspawn container. But sometimes, one wants more than that, for example two shells in the same container. That's something that debspawn seems to be unable to do. Is there any way to fire up a pid-1-systemd isntance inside a debspawn container, so that the container could have an IP address and run its own sshd? Or is there any way to get a login prompt from an already running debspawn container? What magic have other people built around debspawn? Or is everybody using a fully-fledged docker for all non-trivial things? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: merged-/usr transition: debconf or not?
On Fri, 19 Nov 2021 11:58:39 +0100, Philip Hands wrote: >Given that these bugs are going to be utter bastards to reproduce, and >you can be sure that we'll have enough diversity in installed systems >that some people are going to manage to be sufficiently unlucky, it >would be nice to know the sort of damage we might expect. > >It strikes me that we ought to be able to screen our own repos for >packages that could be able to tickle this bug. That would give us the >chance to look at what sorts of files we might realistically expect to >be clobbered, it should give some indication of how many packages we >should expect to be able to trigger this, and knowing this might suggest >plausible work-arounds. This is one of the cases where I wish that Debian would be a more centrally organized project. Red Hat or SuSE would just fix their package management and go on with their business. It's a pity that we have actually THINK about alternatives to that trivial and obvious approach because we leave our core package maintainers too much freedom to stall. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#998844: ITP: oas -- Output Address Selection for outgoing IPv6 connections
Package: wnpp Severity: wishlist Owner: Marc Haber X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: oas Version : (nor formal release yet) Upstream Author : Thomas Noll * URL : https://github.com/ThomasNoll/oas * License : MIT Programming Lang: C Description : Output Address Selection for outgoing IPv6 connections Oas (Output Address Selection) is a wrapper around connect() that allows to choose the source address for outgoing IPv6 connections from programs that don't support this by themselves. In IPv6, nodes might be using multiple IP addresses simultaneously. In fact, this is the normal case in many networks. Different IP networks might be configured with different privileges, making it important to use the correct source IPv6 address for outgoing connections. While many programs allow selecting IPv6 source addresses, others don't. Also, the source address mechanisms provided by the operating system (see RFC6724, ip addrlabel on Linux) have some known shortcomings. For example, Linux takes the routing decision for locally originated datagrams before doing IPv6 source address selection, which might cause the system to send the outgoing datagram to the wrong default gateway where it might be dropped. oas influences the IPv6 source address of an outgoing connection early enough for the routing decision to be taken correctly.
Re: Bug#995189: RFH: isc-dhcp
On Tue, 28 Sep 2021 13:34:12 +0200, Vincent Blut wrote: >Le 2021-09-28 13:00, Marc Haber a écrit : >> On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri wrote: >> >On Sep 28, Noah Meyerhans wrote: >> >> For what it's worth, my preference would be transition to >> >> systemd-networkd with bookworm. >> >I think that a good default would be systemd-networkd for servers and >> >NetworkManager for systems with Wi-Fi or a GUI. >> >> Afaik, NetworkManager uses an external DHCP client and thus is not a >> solution for the problemt hat ISC DHCP client is EOL. > >Starting with version 1.19.90-2, NetworkManager uses its internal DHCP client: Ah, cool. I didn even realize that, congrats for the painless migration. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Bug#995189: RFH: isc-dhcp
On Tue, 28 Sep 2021 18:49:31 +0200, Vincent Bernat wrote: >Make a change, reload your configuration, everything breaks. ifupdown2 >is smart and will converge to the new configuration. Network Manager can >restart and minimize impact. AFAIK, systemd-networkd is as dumb as >ifupdown and does not know how to converge. systemd-networkd is a really nice tool for the server market, as its configuration file structure is really easy to use with configuration management tools like ansible or puppet. And, server configuration rarely changes. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Bug#995189: RFH: isc-dhcp
On Mon, 27 Sep 2021 15:48:25 -0700, Noah Meyerhans wrote: >It's worth noting also that ISC's DHCP client, packaged as >isc-dhcp-client from the isc-dhcp source package, is considered EOL >upstream. Same applies to the relay, doesn't it? Greetings Marc -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Bug#995189: RFH: isc-dhcp
On Tue, 28 Sep 2021 04:15:58 +0200, Marco d'Itri wrote: >On Sep 28, Noah Meyerhans wrote: >> For what it's worth, my preference would be transition to >> systemd-networkd with bookworm. >I think that a good default would be systemd-networkd for servers and >NetworkManager for systems with Wi-Fi or a GUI. Afaik, NetworkManager uses an external DHCP client and thus is not a solution for the problemt hat ISC DHCP client is EOL. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: partman, growlight, discoverable partitions, and fun
On Thu, 23 Sep 2021 23:29:14 +0200, John Paul Adrian Glaubitz wrote: >If not, I don't think it would be a viable replacement for partman. But maybe an alternative? I find the partitioning step one of the most error-prone and hard-to-use parts of non-trivial Debian installations. Greetings Marc -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Freeipa-client in Debian11
On Sat, 4 Sep 2021 09:05:35 +0300, Timo Aaltonen wrote: >On 3.9.2021 19.02, Marc Haber wrote: >> On Fri, Sep 03, 2021 at 01:10:17PM +, Domagoj Bazina wrote: >>> This package is not available in Debian 11 distribution, and version from >>> older Debian 10 can't be installed. Is there any replacement for this >>> package, or are there any plans for implementation of that package in >>> Debian 11? >> >> Packages that didn't make it into a release before the release won't >> make it back into the release after the release. There might be a >> possibility via a backport, but for this to happen, freeipa would need >> to return to testing first. > >My plan was to backport a client-only package, like it was in Buster >(though not via backports). Is that not possible? You're of course free to roll your own, local package. It shold be possible. Just don't expect any official movement in Debian stable, testing or stable-backports until that RC bug is fixed or resolved in some other way. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Freeipa-client in Debian11
On Fri, Sep 03, 2021 at 01:10:17PM +, Domagoj Bazina wrote: > I have question about freeipa-client, that packages was available as > apt-package in Debian 10, also it can be found in Sid option, > https://pkgs.org/search/?q=freeipa-client. Freeipa was removed from Debian 11 due to a long-standing release-cricital bug, #970880. > This package is not available in Debian 11 distribution, and version from > older Debian 10 can't be installed. Is there any replacement for this > package, or are there any plans for implementation of that package in Debian > 11? Packages that didn't make it into a release before the release won't make it back into the release after the release. There might be a possibility via a backport, but for this to happen, freeipa would need to return to testing first. #970880 has not seen action in half a year, so I'd not hold my breath waiting for a backport to appear. > *I've also tried option with adding contribution repository. (apt-get install > software-properties-common apt-add-repository contrib) This is a totally not helping action. Please consider reading a few Debian docs. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
