Re: Binary conflict between Midnight Commander and MinIO Client
On Apr 21, Mathias Gibbens wrote: > While that might work for them, it obviously doesn't at a higher > packaging level. Per Policy Section 10.1, I'm bringing this to d-devel > for any comments or suggestions on my plan for packaging the MinIO > Client. Following what several other distributions have done[2], I'm > planning to name the source/binary packages "minio-client" and the > binary provided from that package will be `mcli`. Go for it, I think that there is no good solution for this case. Everybody who cares then will manually create a mc -> mcli symlink. -- ciao, Marco signature.asc Description: PGP signature
Re: dash and mutt
On Apr 19, José Luis González González wrote: > I even tried to reach dash maintainer privately and he is not even on > the package's field (queried by dpkg), there's someone who is obviosly > fake instead: Andrej Shadura I have met Andrej a few times and I am quite sure that he is real. Or maybe I am part of the plot as well? How can you know? > If this is not solved I will cease to stop using Debian and Debian will > die. OK, good luck with your next operating system. -- ciao, Marco signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Apr 07, Wookey wrote: > I think that's a mistake, and I'm not a fan. Because so far as I can > tell 'use salsa' actually means 'maintain your packages in git'. So > far as I can see it is not possible to use our existing 'uscan, patch, > sbuild, dupload' type workflows with Salsa. And that's why I'm not > using it, and don't want to be made to use it. I started using git quite late and spent really a lot of time trying to understand how it fit in my quilt workflow (I loved quilt), but in the end I figured out that it maps well to a patch unapplied gbp-like workflow: If no changes to the packaging are needed then it's just: uscan --rename gbp import-orig ../package_*.tar.xz dch -v $(cat VERSION)-1 'New upstream release.' git add debian/changelog git commit git tag ... dpkg-source --build . pbuilder build $(ls -1tr ../*.dsc | tail -1) dupload ... Check the rpki-client repository for an example. (Using gbp is not mandatory, but it allows to import with just one command the upstream tar archive or git tree reference.) And now having the full git history of my packages is invaluable when trying to understand what has changed and when. -- ciao, Marco signature.asc Description: PGP signature
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Apr 07, Bernd Zeimetz wrote: > There are more than enough ways to keep the entries based on dns > records in your l3 firewalls uptodate, I can't see how this should > warrant to keep yet another patch Jan^WMarco. Not for the form *.domain.tld. -- ciao, Marco signature.asc Description: PGP signature
Re: Debian 12 released with two RC bugs in Sylpheed
On Apr 07, José Luis González wrote: > I want to know why Debian 12 was released with those two Sylpheed RC > bags, report the incident to you all, know what to do with the > maintainer and kindly request that someone better at the job takes over > Sylpheed maintainance, or otherwise I will become a Debian developer > and package it myself. Big Jia Tan vibe here... -- ciao, Marco signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
On Apr 05, Simon McVittie wrote: > I find that having the upstream source code in git (in the same form that > we use for the .orig.tar.*, so including Autotools noise, etc. if present, > but excluding any files that we exclude by repacking) is an extremely > useful tool, because it lets me trace the history of all of the files > that we are treating as source - whether hand-written or autogenerated - > if I want to do that. If we are concerned about defending against actively I agree: it would be untinkable for me to not have the complete history immediately available while I am working on a package. -- ciao, Marco signature.asc Description: PGP signature
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Apr 02, Colin Watson wrote: > You could use a drop-in unit to wrap sshd in tcpd, as suggested by the > Fedora wiki page? This would avoid exposing sshd's process space to > libwrap and all the stuff it links to by default. This would require to switch to socket activation of sshd, which is not the default for good reasons. -- ciao, Marco signature.asc Description: PGP signature
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Apr 02, Colin Watson wrote: > At the time, denyhosts was popular, but it was removed from Debian > several years ago. I remember that, when I dealt with that on my own > systems, fail2ban seemed like the obvious replacement, and my impression > is that it's pretty widely used nowadays; it's very pluggable but it > normally works by adding firewall rules. Are there any similar popular > systems left that rely on editing /etc/hosts.deny? Yes, people. I object to removing TCP wrappers support since the patch is tiny and it supports use cases like DNS-based ACLs which cannot be supported by L3 firewalls. -- ciao, Marco signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
On Apr 01, gregor herrmann wrote: > > I switched long ago all my packages from tar archives to the git > > upstream tree. Not only this makes much easier to understand the changes > > in a new release, > That's not mutually exclusive. When adding an additional git remote > and using gbp-import-orig's --upstream-vcs-tag you get the best of > both worlds. No: I get nothing of value by doing that and the repository will be cluttered by commits that I do not care about. Also: upstream VCS snapshots. -- ciao, Marco signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
On Mar 31, Russ Allbery wrote: > Most of this is pregenerated documentation (primarily man pages generated > from POD), but it also includes generated test data and other things. The > reason is similar: regenerating those files requires tools that may not be > present on an older system (like a mess of random Perl modules) or, in the > case of the man pages, may be old and thus produce significantly inferior > output. But we do not use older systems to build our packages, so this does not matter. Indeed, long ago I started building inn2 from the git tree, no more tarballs... I switched long ago all my packages from tar archives to the git upstream tree. Not only this makes much easier to understand the changes in a new release, but it also makes possible packaging upstream snapshots. > Just to note, though, this means that we lose the upstream signature in > the archive. The only place the upstream signature would then live is in > Salsa. Totally worth it! -- ciao, Marco signature.asc Description: PGP signature
Re: xz backdoor
On Mar 30, Christian Kastner wrote: > >> Another big question for me is whether I should really still > >> package/upload/etc from an unstable machine. It seems that it may be > >> prudent > > If we do not use unstable for development then who is going to? > Are you both talking about unstable hosts, or unstable chroots, or...? I am talking about our own computers. Obviously everything is built and rebuilt in unstable chroots. But I think that we have to eat our dog food. -- ciao, Marco signature.asc Description: PGP signature
Re: xz backdoor
On Mar 30, Jonathan Carter wrote: > Another big question for me is whether I should really still > package/upload/etc from an unstable machine. It seems that it may be prudent If we do not use unstable for development then who is going to? I think that the real question is whether we should really still use code-signing keys which are not stored in (some kind of) HSM. -- ciao, Marco signature.asc Description: PGP signature
Re: On merging bin and sbin
On Feb 28, Helmut Grohne wrote: > Please allow me to push back on this one as well by raising a few > concerns. Also, I think that the benefits from doing this are tiny, and just adding /usr/sbin/ to the $PATH would solve almost everything. -- ciao, Marco signature.asc Description: PGP signature
Re: Another take on package relationship substvars
On Feb 22, IOhannes m zmölnig wrote:
> While I like the idea in general, I wonder how I could override these
> automatic additions.
> I think there are some packages that even demote `${shlibs:Depends}` to
> Recommends.
E.g. inn2 does:
override_dh_shlibdeps:
dh_shlibdeps --exclude=/usr/lib/news/bin/auth/passwd/auth_krb5 -- \
-dSuggests $D/usr/lib/news/bin/auth/passwd/auth_krb5 \
-dDepends
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: Proposal for how to deal with Go/Rust/etc security bugs
On Jan 25, Wookey wrote: > Luca is quite right here. Ultimately this can only be fixed by these > ecosystems understanding that software in these languages cannot be > sensibly used in distributions until they support modularity and > stability. The rust people make the excuse that they are 'too new' to > define a stable ABI. That was fair enough for a while, but it's > getting to be quite a thin excuse at this point. I think the real The problem here is that many of these upstream developers actually see this as a feature: they are happy to not have "old versions" of their software shipped by distributions, because this way they can tell users to just download the latest pre-built binaries from github or an appimage and not care about supporting older releases. And while this somehow often works for stand-alone desktop or web applications, it is hell for daemons or other system services which need integration with the OS. -- ciao, Marco signature.asc Description: PGP signature
Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)
On Jan 24, Peter Pentchev wrote:
> This might be a minority, optimistic, rose-tinted-glasses kind of
> opinion, but I believe that the state of the Rust ecosystem today
> (I have no experience with the Go one) is quite similar to what Perl and
> Python modules were 25, 20, bah, even 15 years ago. Gradually, with time,
I am not familiar with the Python ecosystem, but I have been writing
Perl and packaging software with Perl dependencies for over 25 years and
I can confidently say that this is not true.
Perl libraries ("modules") generally never had the API instability that
I have seen in Rust libraries (but much less in Go, I believe).
In my experience forward compatibility has always been very important in
the Perl ecosystem.
BTW, for the past couple of years I have been presenting to my other
community, the network operators, about some of my Debian work and these
problems with integrating complex Rust software in distributions, e.g.
https://www.linux.it/~md/text/rpki-validators-euroix2023.pdf .
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: HFS/HFS+ are insecure
On Jan 10, Michael Biebl wrote: > While we could ship such a udev rule for udisks, I don't think it will > properly solve the issue. The device will still show up in nautilus, plasma > etc and mounting is just an additional click away. The threat model here is: somebody connects a crafted USB stick to a computer with a locked screen. Also, the listed file systems are not used or not used anymore on removable devices. Certainly not on removable devices used by regular users. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#810018: New Essential package procps-base
On Nov 20, Craig Small wrote: > Also why is killall5 not a candidate too? Probably because it makes no sense outside of sysvinit, except that as a footgun. (Also, is it equivalent to pkill --inverse?) -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#1053165: ITS: nunit
On Sep 28, Bastian Germann wrote: > Okay. What do you suggest for "team maintained" packages where there is no > active team member? > File MIA processes for each of the uploaders? And then? The MIA team's bugs > are not RC bugs, > so you cannot even NMU them based on the MIA bug. After having verified that none of the current maintainers object (tacit consent is fine) then just NMU them. > I think, just letting such packages rot for one or two decades does not help > anybody, certainly not our users. I agree: you are doing a good thing by caring about abandoned packages. -- ciao, Marco signature.asc Description: PGP signature
Re: Do not plan to support /usr/lib/pam.d for Debian pam
On Sep 16, Steve Langasek wrote:
> While I have applications downstream which also care about empty /etc, the
> current situation is that this wouldn't help because almost all the
> PAM application configs in Debian reference one or more of
> common-{account,auth,password,session,session-noninteractive} which are
> constructed at package install time and therefore are inappropriate to ship
> in /usr.
Actually it would still help a lot, because pam-auth-update can be run
on the first boot to rebuild the /etc/pam.d/*common-* files.
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: Do not plan to support /usr/lib/pam.d for Debian pam
On Sep 16, Russ Allbery wrote: > However, and this is very important, *no one has decided that you get to > do that work in Debian*. I am confident that I have never said otherwise. > Right now, any base system package maintainer could decide that putting > configuration files in /etc makes sense for reasons of their own limited > to their specific package and further break support for booting a system > in this mode, and there are no grounds to ask them not to do this. > Because you don't have an *agreement*. I think that I am allowed to ask all I want at any time (severity: wishlist), but they can also choose to not care. > Accomplishing things like this in Debian has a large social component that > I think is being neglected. After having initiated a few things like this in Debian I suspect that I am beginning to understand why this may happen. -- ciao, Marco signature.asc Description: PGP signature
Re: Do not plan to support /usr/lib/pam.d for Debian pam
On Sep 15, Sam Hartman wrote: > But for the most part PAM appears to just override on a file-by-file > basis. Just like udev, kmod, dbus, etc... PAM is not different. > I have significant discomfort aligning what you say (pam is the last > blocker) with what several people said earlier in the week. > What I heard is that there was no project consensus to do this, and that > people were running experiments to see what is possible. Indeed. I did the experiments and they where unexpectedly positive: pam is the only blocker for booting _the base system_. I never expected that everything would immediately work just fine with an empty /etc: my goal is to have support for this in the base system and selected packages. See for yourself: mkdir /var/lib/machines/empty/ ln -s usr/bin usr/sbin usr/lib usr/lib64 /var/lib/machines/empty/ # this is a workaround for PAM mkdir /var/lib/machines/empty/etc/ cp -a /etc/pam.d /etc/security /var/lib/machines/empty/etc/ # this is a workaround for https://github.com/systemd/systemd/issues/29185 echo ID=unknown > /var/lib/machines/empty/etc/os-release systemd-nspawn --private-network --network-veth -b \ --bind-ro=/usr --tmpfs=/var/ --tmpfs=/tmp/ \ -D /var/lib/machines/empty/ You could add --tmpfs=/etc/ too, but then logins would fail. -- ciao, Marco signature.asc Description: PGP signature
Re: sysadmin configuration of sparse-/etc vs prepopulated-/etc?
On Sep 16, Josh Triplett wrote:
> If we're talking about developing a solution that doesn't already exist,
> why not have that solution *be* the
> notification-and-diff/show-the-defaults mechanism you're describing? For
> instance, provide a declarative mechanism to say "this file/directory in
> /usr is the default version of this configuration file in /etc", with
This is upcoming in a future systemd release, with a new tmpfiles.d(5)
flag adding the semantics "this rule should be only considered on the
first boot".
("first boot" is a systemd term of art which has exactly the semantics
that we need here.)
> standard schemes like 'merge' or 'override'", and then offer a tool
> (similar to the existing systemd-delta but generalized) to show all the
> configuration files that differ, as well as automatic support for
> flagging changes on upgrades and suggesting a three-way merge (similar
> to ucf)?
This is not, but it could be added on top of it by anybody interested.
> With some care for convention-over-configuration, debhelper
> could auto-populate this declarative data in many cases.
This is intriguing. :-)
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: /usr/-only image
On Sep 10, Russ Allbery wrote: > So far as I know, no one has ever made a detailed, concrete proposal for > what the implications of this would be for Debian, what the transition > plan would look like, and how to address the various issues that will > arise. Moving configuration files out of /etc, in particular, is > something I feel confident saying that we do not have any sort of project > consensus on, and is not something Debian as a project (as opposed to > individuals within the project) is currently planning on working on. Indeed, at this point we are just experimenting and trying to figure out what we can and cannot do. I am not even sure that general distribution-wide support for this is a reasonable goal, but I expect that it will not be hard to have support for the base system and cooperating packages. -- ciao, Marco signature.asc Description: PGP signature
Re: /usr/-only image
On Sep 10, Nils Kattenbeck wrote: > I am looking to generate a Debian image with only a /usr and /var > partition as per discoverable partition specification. However, it > seems to me like the omission of /etc leads to several issues in core > packages and logging in becomes impossible. > Is this an unsupported use case and if yes, is there ongoing work to > eventually support this? There are some people generally working in this area, but I fear that we are still far from being able to support an empty /etc/. Still, it would be very good to start documenting what needs to be fixed. I suggest that you join #debian-systemd. -- ciao, Marco signature.asc Description: PGP signature
Re: What licenses should be included in /usr/share/common-licenses?
On Sep 10, Enrico Zini wrote: > I like this. I'd say that even if a license is shorter than 25 lines I'd > appreciate to be able to link to it instead of copypasting it. Me too. > I like to be able to fill the license field with a value, after checking > that the upstream license didn't diverge from what it looks like. I'd > love to use SPDX IDs there, for example. In an ideal world, I'd like to > autofill debian/copyright with SPDX IDs from upstream metadata. Having a > link to a file goes closer to having a declarative license ID. Agreed. -- ciao, Marco signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
On Aug 15, Jonas Smedegaard wrote: > The proper approach is IMO one of these: Or else, if you know that they do not actually need to be rebuilt: just disable in the makefile the target which causes them to be rebuilt. This is what I do in my packages. -- ciao, Marco signature.asc Description: PGP signature
Re: HFS/HFS+ are insecure
On Jul 21, Bastien Roucariès wrote: > Ok found it call mountlo outdated > will need a small patch for linux uml, but may be worthwhile > Last version seems to be outdated 0.6 and carried by slitaz distribution. > May be time to revive it It looks like a good long term solution, but as long as there are insecure file systems in the kernel they should be disabled by default so these are really different issues. I remember noise from the systemd people about mounting removable media using user space drivers, but I do not think that anybody is working on this. -- ciao, Marco signature.asc Description: PGP signature
Re: HFS/HFS+ are insecure
On Jul 21, Matthew Garrett wrote: > > You are totally correct. > > Kernel team, please blacklist HFS/HFS+ for automounting. > Isn't this a userland policy decision? udisks will happily trigger a > module load for hfsplus if udev has identified it, and I don't think > there's a trivial mechanism for the kernel to disable that. I believe Yes, I was also thinking about this and I believe that you are right. The kernel team did this in the past for some uncommon network protocols, but they could do it themselves because these modules are autoloaded using aliases. Since I happen to be the kmod maintainer it looks like that solving this is on me. :-) Unless somebody has a better idea then then my plan is to ship in the next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist directive to prevent automatically loading some file system modules. By looking at the MAINTAINERS file I have identified these file systems marked as "orphan" and "odd fixes": efs hfs hfaplus qnx6 sysv affs ecryptfs jffs2 jfs And I think that I can also safely add a few more which while actively maintained I believe are only used in a retrocomputing context or are generally uncommon anyway: befs bfs hpfs omfs qnx4 reiserfs spu ufs Did i miss anything? I think that all of these have enough of a niche usage that it would not be an unreasonable burden for the affected users to manually load the modules when needed (ad hoc or using /etc/modules-load.d/). -- ciao, Marco signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Jul 11, Sam Hartman wrote: > 1) It's an extra layer. You can ignore it when reading the config (at > least if you aren't too surprised by your config ending up in /run). > But it is extra complexity, especially in a situation like " run dhcp on > my ethernet" that is relatively simple. I agree. I do not really see the value of netplan in a default install and it brings a lot of complexity (and Python!) which is not usually needed. -- ciao, Marco signature.asc Description: PGP signature
Re: systmd-analyze security as a release goal
On Jul 04, Andrey Rakhmatullin wrote: > Cool but looks like a lot of work. I do not think that this is really a lot of work. > Is it possible to do this without > applying the flags one by one and testing the result? Is it easier to You may intimately know what the daemon needs to do and how the sandboxing features work, and be able to mentally create a correct and complete configuration. > start with applying all of them and then looking what needs to be > disabled? This is what I do. -- ciao, Marco signature.asc Description: PGP signature
Re: systemd-analyze security as a release goal
On Jul 04, "Trent W. Buck" wrote: > * If it runs its own process manager (e.g. postfix's "master"), > don't bother trying to harden it. I disagree. It may not be possible to use NoNewPrivileges, but at least file system hardening is usually trivial to enable for most daemons. > * If it sends mail via /usr/sbin/sendmail, > don't bother trying to harden it. See above. > If it sends mail via smtp://localhost, that's MUCH easier. > Start encouraging upstreams to do that instead? Do you know an appropriate C library that could be used? Speaking proper SMTP is a bit harder than rfc821 | sendmail, so let's try to not overshoot... > Moving pidfiles from /run/%p.pid to /run/%p/%p.pid and > letting systemd do the User=%p can help quite a bit. In general, all services should be STRONGLY encouraged to use RuntimeDirectory, StateDirectory, etc... Also because this makes possible implementing the "file system factory reset" patterns. -- ciao, Marco signature.asc Description: PGP signature
Re: systmd-analyze security as a release goal
On Jul 03, RL wrote: > (One of the issues for services that send email is that it is very > easy to break exim) NoNewPrivileges breaks by design anything which depends on suid, so Exim and (in the default configuration) Postfix. I agree that we should do much better in terms on sandboxing, considering that it is so easy with systemd. I am not sure if it can be a release goal, but it definitely should be a best practice. This is a good example of what an almost fully sandboxed service looks like: https://salsa.debian.org/md/rpki-client/-/blob/master/debian/rpki-client.service -- ciao, Marco signature.asc Description: PGP signature
Re: Proposed MBF - removal of pcre3 by Bookworm
On Jul 02, Peter Pentchev wrote: > On the other hand, the bugs have been open for an year and a half now... For something which has worked just fine for many years. -- ciao, Marco signature.asc Description: PGP signature
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Jun 22, Martin-Éric Racine wrote: > The point has always been to ship some ifupdown-supported DHCP client > by default. This can be done either by keeping the default client's > priority to important or by making ifupdown Depends on one. I prefer > the later. It would be totally unacceptable to make ifupdown Depend on a DHCP client, because this would bloat most server installations. But I would be happy with a Recommends. It's not like the people whose server needs a DHCP client do not know that they need to install one. -- ciao, Marco signature.asc Description: PGP signature
Re: booststrapping /usr-merged systems
On Jun 09, Bjørn Mork wrote: > > as we all know every Debian maintainer can veto any systemic changes > > that they do not like. > I don't think qusr-merge would not have happened if this was true. And > I believe you know that very well. Actually merging /usr happened in a suboptimal way because I had to work around this lack of collaboration, so yes: this is true. It happened, but despite the vetoes. -- ciao, Marco signature.asc Description: PGP signature
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On Jun 08, Raphael Hertzog wrote: > In the same spirit, I'd like to throw an idea... could we decide that > base-files is the first package to be configured as part of the bootstrap > protocol and change base-files maintainer's scripts into statically linked > executables so that they can work even if we don't have the library loader > on the ABI-compliant path? It could be even easier: base-files could be unpacked once without running the maintainer scripts and then "reinstalled" again later as usual. > And creating the required symlinks would be done by those (standalone) > maintainer scripts... > > I don't know if we already have some rule/invariant in the configuration > order of the unpacked packages, but I doubt so. Indeed, this would be very simple and it has already been proposed. But somebody then complained that special-casing a package would violate the design contraints he self-imposed to his own image building tool, and as we all know every Debian maintainer can veto any systemic changes that they do not like. -- ciao, Marco signature.asc Description: PGP signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Jun 06, Simon McVittie wrote: > When considering the future of i386, a factor that we need to bear in > mind is that there are two major use-cases for i386, with requirements > that sometimes conflict: Agreed. I will be more blunt: an i386 port which cannot run old i386 binaries would be almost useless. -- ciao, Marco signature.asc Description: PGP signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
On May 18, Steve Langasek wrote: > So maybe the best workaround in the short term, if there's no immediate data > migration path, would be to change the inn2 source to use unsigned long in > place of time_t in the data format? I do not think that inn2 is going to be a problem, because it has been built with --enable-largefiles for quite a few releases (and yes, switching was a bit traumatic for the 32 bit systems involved). OTOH, inn will be affected. But inn systems are small enough nowadays that users can just rebuild the database. -- ciao, Marco signature.asc Description: PGP signature
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On May 17, Helmut Grohne wrote: > Given the feedback, I am convinced that changing PT_INTERP is a stupid > idea regardless of whether it is technically feasible. There must be a > better way. Let's step back a bit. Me too, I was never persuaded. > 4. Change the bootstrap protocol. In essence, this has been attempted > in debootstrap by creating these symlinks prior to unpack, but no > consensus has evolved around this approach yet. The category is > wider though and generally requires changes to all bootstrapping > tools. I think that this is being dismissed too easily, mostly because the mmdebstrap maintainer has been fighting it due to a philosophical preference. > Moving on to category 4 feels rather obvious, especially because work > has been done there in debootstrap. The approach in debootstrap however > is one that I see as a dead end, because it causes us to maintain this > code multiple times. It's the number of derivatives times the number of > bootstrap tools and that doesn't scale. But the code is trivial. It is currently more complex than it is needed in debootstrap only because initially it needed to support the biarch libc packages, but since nowadays they create the top level symlinks themselves then it can be made as simple as: for dir in bin sbin lib; do ln -s usr/"$dir" "$TARGET/$dir" mkdir -p "$TARGET/usr/$dir" done Indeed, usrmerge does not have any architecture-specific knowledge anymore. > https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap. In particular, > making architecture bootstrap become chrootless would likely be a > generic solution to this and other problems. However, any change needs > to propagate to a stable release in all bootstrapping tools. Therefore > we cannot reasonably finish the transition before forky. This makes Why not? > So what's left is category 1. I looked into what the minimum set of > files to be retained could be. To do that end, I moved everything and > then reverted as much as was needed to make bootstrapping work. > * /lib64/ld-linux-x86-64.so.2 (hopefully obvious) > * /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (link target) > * /bin/sh (hopefully obvious) > * /bin/dash (link target) Interesting approach. If it is so much simple, why are you not persuaded that it could be a good solution until the bootstrapping tools are updated? > * /bin/bash (usrmerge runs ldd, which is a #!/bin/bash script) > * /bin/more (update-alternatives doesn't like its absence) > * /bin/cp (unless usrmerge stops hard coding its path) These can be easily fixed, maybe the ldd issue too. > The other major takeaway is that a significant > chunk of the problems mentioned in this mail cannot be fixed by > modifying dpkg only. Agreed. -- ciao, Marco signature.asc Description: PGP signature
Re: DEP 17: Improve support for directory aliasing in dpkg
On Apr 27, Helmut Grohne wrote: > The origin of this thread was a proposal to adapt dpkg. Your mail No, Marc is right. The origin of this thread is trying to find workaround because the dpkg maintainer refused long ago to implement a simpler solution. -- ciao, Marco signature.asc Description: PGP signature
Re: setting sysctl net.ipv4.ping_group_range
On Apr 12, Helmut Grohne wrote: > As much as I like unprivileged operation, I think this change may expand > privileges beyond what we expect. At present, ping limits an > unprivileged user to a minimum spacing of 2ms and prevents a flood ping. > Of course a user can just run multiple ping processes in parallel to > overcome this limitation. Real life DoS attacks from unpriviledged account are made with udp.pl and they are already quite damaging, so I do not believe that adding an ICMP option would make the situation worse. -- ciao, Marco signature.asc Description: PGP signature
Re: Unlock LUKS with login/password
On Mar 10, Stephan Verbücheln wrote: > On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote: > > In the future the initramfs will (usually) be static as well. > Can you provide more information on that? Due to multiple reasons, mostly related to secure boot and boot attestation, there is significant interest by distributions in providing static and signed initrds. BTW, I have been informed that "initramfs" is an obsolete term and that we are back to "initrd" like in the '90s. Some people in Debian are interested in working on https://github.com/systemd/mkosi-initrd, which will provide a static initrd built from system binaries and extensible using the systemd-sysext and future systemd-sysconf mechanisms for things like SAN boot or sshd in the initrd. Do not look too hard at it at this point: the upstream developers are going to make soon a new release with significant changes. I expect that people interested in working on initramfs-tools can probably extend it with little work to generate static images suitable for the most common deployments. People with uncommon ones will have to do without the modern boot attestation features or else sign their own images (which will be very easy once I, or somebody else, will have packaged sbctl). Obviously there are no new requirements for the systems without secure boot. -- ciao, Marco signature.asc Description: PGP signature
Re: Unlock LUKS with login/password
On Mar 10, Stephan Verbücheln wrote: > Apart from the fact that UEFI Secure Boot is an overly complex monster > which is basically broken[1] by design, my understanding of it is also > that it does not protect configs, initramfs etc. in /boot. It only > protects the kernel image and loaded modules. It can, with an appropriate configuration. > In addition, files in /boot like the initrd are generated individually > and may contain files not limited to what someone puts into /boot > intentionally. In contrast to /boot/efi, /boot does not only contain > static files delivered by the distribution. In the future the initramfs will (usually) be static as well. -- ciao, Marco signature.asc Description: PGP signature
Re: Unlock LUKS with login/password
On Mar 08, Alexey Kuznetsov wrote: > 1) grub can ask for a login/password, then MD5 the text and unlock the LUKS Forget about this part: encrypted /boot/ is pointless from a security point of view and this complexity does not belong in the boot loader. Once you accept this then you will end up with a design very similar to https://www.freedesktop.org/wiki/Specifications/login-unlock/ . So you would need to implement having Plymouth or whatever else storing the credentials in the kernel keyring and then probably a PAM module that will make them available to the rest of the stack (notably pam_gnome_keyring). -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#995189: RFH: isc-dhcp
On Mar 08, Philipp Hahn wrote: > Do we do our users a service by keeping that dead horse alive for another 2+ > years? While being quite stable it had a steady stream of security issues: Yes, unless you know of other implementations with that features set. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#995189: RFH: isc-dhcp
On Mar 07, Philipp Hahn wrote: > Is it a good idea to keep it alive for another 2+ years in > Debian-12-Bookworm or should it be removed now? > https://packages.debian.org/source/bookworm/isc-dhcp I do not think that it should be removed at this point, since there is a need for the complex features that isc-dhcpd can provide and there are is no obvious replacement: Kea is super complex (and I do not know if it has all the features) and everything else is too much simple. -- ciao, Marco signature.asc Description: PGP signature
Re: Yearless copyrights: what do people think?
On Feb 22, Peter Pentchev wrote: > So I've seen this idea floating around in the past couple of years > (and in some places even earlier), but I started doing it for > the couple of pieces of software that I am upstream for after reading > Daniel Stenberg's blog entry: > https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/ Good idea, I planned to do it myself too in the future. -- ciao, Marco signature.asc Description: PGP signature
Re: depends-on-obsolete-package lsb-base
On Jan 20, Simon McVittie wrote: > For the systemd-sysv-generator case, the LSB init script is only run if > there is no native systemd unit of the same name, which itself triggers > a Lintian warning (albeit quite a common one); so hopefully if maintainers > are removing lsb-base dependencies as prompted by Lintian, they are also > adding a corresponding /lib/systemd/system/foo.service for each > /etc/init.d/foo in the package. I think that it is time to upgrade the warning, because I understand that interest in continuing to maintain systemd-sysv-generator is waning. I will be happy to assist maintainers who want to add a .service unit to their package but are unsure about the details. -- ciao, Marco signature.asc Description: PGP signature
Re: setting sysctl net.ipv4.ping_group_range
On Jan 03, Adam Borowski wrote: > Debian's default sysctl settings should reside in procps (as it owns > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated > package. Nowadays systemd is a source of common sysctl settings among different distributions. -- ciao, Marco signature.asc Description: PGP signature
Re: setting sysctl net.ipv4.ping_group_range
On Jan 02, Noah Meyerhans wrote: > I'm entirely happy to reassign this request to systemd and have the > setting applied more broadly. The question that arises then is what to > do about the file-level capabilities on the ping binary. Ideally we > drop them entirely (including the setuid fallback), but when? Some options: - conflict with systemd < version_with_the_new_default - wait for a full release and then just drop it - when sysctl in postinst reports the new default - a mix of the last two options I suggest that you improve the ping error message to also mention the sysctl (or maybe an appropriate writeup in README.Debian?). -- ciao, Marco signature.asc Description: PGP signature
Re: setting sysctl net.ipv4.ping_group_range
On Jan 02, Noah Meyerhans wrote: > With that in place, unprivileged users are able to excute ping for both > IPv4 and IPv6 targets without cap_net_raw (currently set as either a > file-based attribute on the ping binary or acquired via setuid). But > since that applies system-wide, not just to the ping binary, there may > be objections. I do not think that the submitter made clear why this would be preferable, so I had to research it myself. See: https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange https://github.com/systemd/systemd/pull/13141 Since this is one of the systemd sysctl defaults (of which I think that we should adopt more, especially the network-related ones!) I agree with changing this. I would just do it in the systemd package package to allow all packages to benefit from it without having to care if ping is installed. -- ciao, Marco signature.asc Description: PGP signature
Re: setting sysctl net.ipv4.ping_group_range
On Jan 02, Peter Pentchev wrote: > I personally would prefer giving the administrator a way to change that. > Maybe add a low priority debconf question with a "ping is not setuid" > default, then mention that debconf setting in a comment in the file that > the package installs in the sysctl.d/ directory. Please don't. There are already way too many debconf questions and this one would be totally pointless: anybody who cares to change the default can just locally override the /usr/lib/sysctl.d/ file with a drop-in in /etc/sysctl.d/ . > Other than that, I think making ping not setuid is a great idea. ping is (generally) not setuid. -- ciao, Marco signature.asc Description: PGP signature
Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)
On Dec 09, Andreas Tille wrote: > I would consider asking upstream about this for sure but the code is in > maintenance mode and there is no Git repository to step back in history. > The only way to go would be to take configure.ac from a later version > and find out how it can be tweaked to create some working configure > file from it. I do not consider my time well spent in doing so except > if there is some consensus here on the list that configure files without > configure.ac are "missing source". If there is no surviving configure.ac which can generate the current configure file then it is quite obvious that this is not a DFSG issue, because no such source exists. But if your package contains a manually edited configure file then this is a bad practice, and experience shows that sooner or later you will have to deal with the resulting bugs. Clearly, the severity of these bugs is different, at least as long as your package builds. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
On Nov 13, Robie Basak wrote: > This seems inconsistent to me. Where is the expectation that TMPDIR must > be unset if dropping privileges coming from? Obviously for users of Where is the expectation that $TMPDIR is writable by any user but the current one? I do not believe that it is expected that if a user creates a directory and points $TMPDIR to it then they also have to make it sticky, so this has nothing to do with libpam-tmpdir. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#1023778: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
On Nov 13, Simon McVittie wrote: > I think you can both be right. The symptom here is a maintainer script > failing, but if I'm understanding Marco's argument correctly, he's > saying that the root cause is that when you switch between execution > environments, not all of the environment variables inherited from the old > execution environment are appropriate for the new one. (A similar thing > can happen for other inheritable process parameters like resource limits.) Yes, but this is a general issue and not relevant for this specific case. Because let's consider an environment in which: - there is no relevant elevation of privileges, so discussions about what should libpam-something, sudo, etc... do are not applicable - the root environmente legitimately has TMPDIR=/tmp/root-only/ mode 700 - a maintainer script does something as an unprivileged user which needs to access $TMPDIR so you correctly noted that: > If the maintainer script is *dropping* privileges from root down to a > system user, then I think the maintainer script is/should be responsible > for doing that privilege drop in a way that works - but ideally the > maintainer script should be delegating that responsibility to a common > tool rather than open-coding it itself, either by launching a one-shot > system service that the init infrastructure can run in a predictable > execution environment, or using a common privilege-level-switching tool > like runuser, su or sudo, or using an IPC-based "run this command in a > more controllable enviroment" tool like systemd-run. And I think that it would be wrong to have dpkg generally unset $TMPDIR, because if root sets it then it would be reasonable to expect that also dpkg and the maintainer scripts use it (as long as they are not dropping privileges). -- ciao, Marco signature.asc Description: PGP signature
Re: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
On Nov 12, Otto Kekäläinen wrote: > Instead of manually trying to manage TMPDIR env variable in various > places, we should have a standardized way to run maintainer scripts in > clean shell sessions that have all env variables set automatically > correctly. This is not about maintainer scripts, but about programs which change the UID without sanitizing the environment. -- ciao, Marco signature.asc Description: PGP signature
Re: TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
On Nov 10, Robie Basak wrote: > Thank you for the report. Adding debian-devel@ and the libpam-tmpdir > maintainer for wider discussion. > > On Thu, Nov 10, 2022 at 12:54:34AM +, brian m. carlson wrote: > > On my systems, I use libpam-tmpdir, which provides each user with a > > private temporary directory owned and accessible only by them under > > /tmp/user/UID (e.g., /tmp/user/1000). PAM sets the TMPDIR variable to > > this value upon creating a session. > > > > When I upgrade mysql-server-8.0, it is obviously as root, so TMPDIR is > > set to /tmp/user/0. This value does not work since MySQL doesn't run as > > root, and so MySQL fails to start after upgrade in such a configuration, > > like so: > > I think I understand the problem. > > But are you in essence saying that libpam-tmpdir requires that *every > maintainer script* that runs things as non-root, or starts processes > that do that, unset TMPDIR first? This would not be right, because it is totally valid to set $TMPDIR for the root user too. The real issue here is that TMPDIR, like some other variables, should not be propagated when switching privileges from the user to root. But here we have ANOTHER issue: whatever ends up initialising mysql does not run as root, but still uses $TMPDIR provided by the root environment. Since there is no guarantee at all that $TMPDIR can be accessed (not just be writeable!) by other users then in this case it is correct to request that the package ignores $TMPDIR. -- ciao, Marco signature.asc Description: PGP signature
Re: Enabling branch protection on amd64 and arm64
On Nov 01, Sebastian Ramacher wrote: > > this change is only targeted at two archs, which I'd hope could cope with > > it. > If we ignore/break MA: same co-installability, sure. Sure, but this means that a much smaller subset of packages will need to be rebuilt on all architectures. -- ciao, Marco signature.asc Description: PGP signature
Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab
On Oct 14, Vincent Lefevre wrote: > > This is obviously convenient on Guillem's part, but we have to optimize > > systems by default for the general case and not just for dpkg -i. > This dpkg FAQ says that this is not beneficial for just dpkg, > but also "for any application in the system". [citation needed] I hope that you understand why at this point I cannot trust as is the opinions of the dpkg maintainer. -- ciao, Marco signature.asc Description: PGP signature
Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab
On Oct 14, Vincent Lefevre wrote: > > This is not "the Debian FAQ" but "the DPKG FAQ", which has been known to > > recommend awful things in the past. > But it is still considered in the present times by the dpkg developers. > Bug 923423 was closed several hours ago based on this dpkg FAQ: This is obviously convenient on Guillem's part, but we have to optimize systems by default for the general case and not just for dpkg -i. > (the issue here is that there is a fsync for *every* file, so that for And at this point I am wondering if this is a good design, or if it would be better to use a different strategy. -- ciao, Marco signature.asc Description: PGP signature
Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab
On Oct 14, Vincent Lefevre wrote: > The /etc/fstab file is created using by default ext4 with just > the errors=remount-ro option. However, the Debian FAQ recommends > the nodelalloc mount option to avoid performance degradation and > preserve data safety: This is not "the Debian FAQ" but "the DPKG FAQ", which has been known to recommend awful things in the past. There is a reason if delayed allocation is enabled by default and this should not be changed without a detailed analysis. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug email is not getting to me
On Sep 30, Sean Whitton wrote: > ARC is meant to be an alternative to this, eventually, right? Right, but it has been such for so many years now that I am not holding my breath waiting for it. -- ciao, Marco signature.asc Description: PGP signature
Re: transition to usrmerge to start around 2022-09-15 (next Thursday)
On Sep 18, Bjørn Mork wrote: > So if you don't want another round of pointless discussions, then I > suggest that you start working on those bugs now. That's the smart thing In other words, you are saying that if we don't do what you want then you will keep rehashing the same old arguments. This looks like extortion to me. > to do if you want to make *sure* usrmerge is part of the release. If > there is no conflict between release goals, then there will be no need > for a discussion. "That's a nice feature you have there, it would be a shame if something happened to it..." > I find it quite disappointing to read https://bugs.debian.org/848622 . I > don't know if it is arrogance or ignorance, but this bug is undoubtedly > caused by usrmerge: And our position is that it needs to be fixed in dpkg. -- ciao, Marco signature.asc Description: PGP signature
Re: A mail relay server for Debian Members is live
On Aug 15, Ansgar wrote: > To not look like forged mail, the "From" header field (not the > envelope) has to be validated with either DKIM or SPF. disroot.org > says this is supposed to be the case for mail from their domain: Not exactly. DMARC validation requires that at least one of DKIM or SPF is aligned. DKIM validates the 822.From header, while SPF validates the 821.From envelope sender. Forwarding emails does not break DKIM signatures, as long as the signed headers are not modified (and they are not supposed to be, so usually it is fine). Forwarding emails does break SPF, and this is what SRS fixes (by changing the sender domain, so this does not help with DMARC). Mailing lists always break SPF and they may or may not break DKIM depending if they change e.g. the message body or the Subject header. The BTS does both, so after years it is still incompatible with DMARC validation (OTOH, domains which are not phishing targets should not enable DMARC. But we cannot fix other people's systems...). -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
On Jul 14, Marc Haber wrote: > >And I see you uploaded ~immediately - why even bother with an ITP? > Is it proper procedure to upload without an ITP? Is there any point in an ITP if you are already ready to upload the package? No. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.
On Jun 30, Stephan Verbücheln wrote: > As far as I understand it, the main point of BabaSSL is to add support > for Chinese developed ciphers and algorithms. Is supporting Chinese cryptography standards a goal for Debian? If it is then they should be available to all packages, but if it is not then I am not sure that having random (?) packages depend on an OpenSSL alternative would be a good strategy. > Long time ago in my student years, I was working with a German fork of > OpenSSL. The point was to add German elliptic curves (BSI and Deutsche > Telekom). They were eventually merged into OpenSSL. Do you expect that support for the Chinese algorithms will be merged in OpenSSL any time soon? Is there such a plan by the BabaSSL developers? -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.
On Jun 22, Lance Lin wrote: > Yes, from my understanding it is a "drop in" replacement for OpenSSL. One of > my packages (Workflow) uses it but can also use OpenSSL. > > I think this package will be beneficial to the Workflow users and downstream > OS's. Can you explain exactly what benefits these users have from using BabaSSL instad of OpenSSL? And why only these users and not the users of other current dependencies of OpenSSL? -- ciao, Marco signature.asc Description: PGP signature
Re: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.
On Jun 17, Lance Lin wrote: > - BabaSSL is a modern cryptographic and secure protocol library > developed by the amazing people in Alibaba Digital Economy. What is the plan? Are there any current or new packages which will depend on it? -- ciao, Marco signature.asc Description: PGP signature
Re: how to convey package porting details?
On Jun 06, Holger Levsen wrote: > > Is this really worth the effort, considering that probably RISC-V is > > going to be our last port for a very long time? > you mean like 640kb should be enough for everyone? :) More like "free ABI is eating the world". I do not see much future for the architectures mentioned here except maybe loongarch64 as a geopolitical tool, but sure: no objections if the people who actually work on ports think this is worthwhile. Maybe the usual suspects which require significant porting work could start documenting instructions for porters in debian/README.source. -- ciao, Marco signature.asc Description: PGP signature
Re: how to convey package porting details?
On Jun 06, Paul Wise wrote: > There are lots of packages that need porting to every new architecture > that comes along. There are others that don't require porting but > benefit in some way from porting to some aspect of the architecture. Is this really worth the effort, considering that probably RISC-V is going to be our last port for a very long time? -- ciao, Marco signature.asc Description: PGP signature
Re: Prove di pacchettizzazione...
On May 05, Marco Gaiarin wrote:
> override_dh_auto_configure:
> dh_auto_configure -- --docdir=${prefix}/usr/share/doc/vchanger
Direi che deve essere --docdir=\${prefix}/...
> e comunque i file vengono installati nella cartella di prima:
Questo potrebbe essere un bug del makefile.
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: feedback for NEW packages: switch to using the BTS?
On Apr 28, Paul Wise wrote: > During the discussions about NEW on debian-devel in recent times, I had > the idea that instead of the current mechanism of sending REJECT mails, > Debian could switch to using the BTS for most feedback on NEW packages. This looks like a good idea to me, but I think that the big problem which needs to be solved is not discussing REJECTs but the packages which stay in NEW for many months with no feedback. -- ciao, Marco signature.asc Description: PGP signature
Re: Keep both images but stop pretending no-free is unofficial
On Apr 19, Sam Hartman wrote: > For example I would thinki it would be entirely reasonable for someone > to want to include a version of Debian installer for use with qemu in an > environment that needed to be DFSG free. > Similarly, I think it would be reasonable for someone to want to provide > entirely free Debian media along with a libre laptop. While I do not expect that this is a significant use case I think that it would be an acceptable compromise to ask the CD team to continue producing both image sets for another one or two releases and then evaluate how much the totally-free images will actually have been downloaded. -- ciao, Marco signature.asc Description: PGP signature
Re: Firmware - what are we going to do about it?
On Apr 19, Steve McIntyre wrote: > What would I choose to do? My personal preference would be to go with option > 5: > split the non-free firmware into a special new component and include that on > official media. I agree, and actually I have been supporting this position for 20 years (time flies!). Just a note: on board wired Ethernet adapters used in popular servers from many vendors have needed the tg3 or bnx/bnx2 firmwares to work for quite a long time, so I do not think that the situation has "recently" worsened. -- ciao, Marco signature.asc Description: PGP signature
Re: What to do with merged /usr and dpkg-fsys-usrunmess
On Apr 06, Krzysztof Sobiecki wrote: > Now what I'm supposed to do? Wait for dpkg-fsys-usrunmess-unmess? Install the usrmerge package and hopefully everything will be fixed. > Is my system broken because I have used dpkg-fsys-usrunmess(that dpkg > advised me to do?). Maybe. > As a Debian user I'm confused and a bit angry. And you have every right to be. Sorry, blame the dpkg maintainer. > What is way forward? Merged /usr. -- ciao, Marco signature.asc Description: PGP signature
Re: Q: systemd-timer vs cron
On Mar 14, Paul Wise wrote:
> AFAICT OnSuccess/OnFailure services don't recieve the output of the
> succeeding/failing service. So the mail sending service needs to dig
> around in the systemd journal. Or make the service output go to a file,
> FIFO or socket and then send that to a mail.
Yes, this is true. These are the unit and script that I use, and I think
that Debian would benefit from having something like this available in
some common package.
I think that there is still space for cron jobs and for having a cron
package installed by default, but also that packages should seriously
consider migrating their cron jobs to timer units.
admin@rs1:~$ cat /etc/systemd/system/status-email@.service
# Add this to the unit to be monitored:
#
# [Unit]
# OnFailure=status-email@%n.service
[Unit]
Description=Status mailer unit for %i
[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email n...@minap.it
Environment=FAILED_UNIT=%i
Environment=HOSTNAME=%H
admin@rs1:~$ cat /usr/local/bin/systemd-email
#!/bin/sh -e
if [ "$1" ]; then
MAILTO="$1"
else
MAILTO="root"
fi
if [ -z "$FAILED_UNIT" ]; then
echo "\$FAILED_UNIT is not set!" 2>&1
exit 1
fi
fuu=$(systemctl show $FAILED_UNIT --property=User)
fuu="${fuu#User=}"
if [ "$fuu" ]; then
shortfrom="$fuu@${HOSTNAME%%.*}"
else
shortfrom="$root@${HOSTNAME%%.*}"
fi
exec /usr/sbin/sendmail -t < $FAILED_UNIT
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Auto-Submitted: auto-generated
$(systemctl status "$FAILED_UNIT" --full --lines=100)
EOF
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: systemd-sysusers [Re: Seeking consensus for some changes in adduser]
On Mar 11, Simon Richter wrote: > We currently don't have a good mechanism for leaving configuration behind on > purge, which we've historically done with user accounts to avoid reuse of > UIDs that may own resources, so we'd still have to create the declarations > from a postinst. While this is a reasonable concern I do not think that it is generally true nowadays for system processes. Also thanks to piuparts, nowadays packages that leave files around after being purged should be a really small number. Actually I cannot think of any, so this should be considered the exception rather than the norm. So I totally support transitioning to systemd-sysusers. -- ciao, Marco signature.asc Description: PGP signature
Re: proposed MBF: packages still using source format 1.0
On Mar 06, Lucas Nussbaum wrote: > I think that we should reduce the number of packages using the 1.0 format, as > (1) format 3.0 has many advantages, as documented in > https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes to > standardization of packaging practices, lowering the bar for contributors to > contribute to those packages. inn is a bit peculiar. It uses a patch system, has no direct changes and is maintained in a VCS. But the build process is from a different age and quite arcane, and I remember that switching to 3.0 would have required significant work, so I see no compelling reason to do it. -- ciao, Marco signature.asc Description: PGP signature
Re: Gmail bounce unauthenticated @debian.org addresses
On Mar 04, Baptiste Beauplat wrote: > Looking at your email headers, I would guess that gmail is already doing it. > > X-Google-DKIM-Signature: v=1; a=rsa-sha256... > > There is somewhat some irony in Gmail blocking email without a DKIM > signature while they are using a non-standard header that other > provider/tools might miss. Just a thought. No irony, you are just missing the point. gmail uses this X header for internal purposes, and there is no DKIM signature because the message has a @debian.org 822.from address hence gmail obviously lacks a valid key for it. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
On Jan 23, Richard Laager wrote: > It might be technically possible to build a binary package with different > versioning, but even if it is: 1) I don't know how, and 2) I'm not sure > whether that's a good idea, especially compared to the alternatives. I did it long ago, I think for kmod taking over module-init-tools: you just need to add an appropriate Version field to debian/control. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
On Jan 19, Paride Legovini wrote: > That's what I had in mind, but the other option: > > > Another option would be to have src:ntpsec build the bin:ntp dummy > > package and remove src:ntp entirely. > > also looks sensible to me after all. No strong opinion. I think that this would be better since they are close enough that ntpsec can usually be a drop-in replacement. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
On Jan 18, Michael Biebl wrote: > I think Fedora prefers chrony instead of ntpsec. Fedora even uses btrfs, so who cares. :-) The interesting point is that RHEL switched to chrony for RHEL 7. Also, I want to add that chrony is not just better as a client, but also as a NTP server. https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/ offers quite some insights. > If "ntp" the binary package would become a transitional package that > installs chrony, that'd be fine with me if that eases the transition. I am not sure that this would be practical since they cannot share the same configuration. I have no objections if somebody wants to work on packaging ntpsec, but I do not think that either ntp or ntpsec should be promoted over chrony nowadays. -- ciao, Marco signature.asc Description: PGP signature
Re: The future of src:ntp
On Jan 17, Bernhard Schmidt wrote: > What do you think? chrony is MUCH better since Debian 10, I agree that it should be the preferred NTP client for when systemd-timesyncd is not enough. You can definitely spend your time on something more fun and more useful. -- ciao, Marco signature.asc Description: PGP signature
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Dec 30, Scott Kitterman wrote: > I would too. It would be nice if systemd-resolved had some mechanism to > support this kind of functionality. If you're going to replace resolvconf, > then you ought to actually replace it. systemd-resolved is supposed to forward queries to the upstream resolver and always be available on 127.0.0.53, so what does actually change in resolve.conf when using it? -- ciao, Marco signature.asc Description: PGP signature
Re: scp non funziona più su debian testing a causa del router
On Dec 12, Giuseppe Sacco wrote: > debug1: Sending command: scp -v -f key-transition-2014.txt > Timeout, server master.debian.org not responding. MTU. -- ciao, Marco signature.asc Description: PGP signature
Re: Extending debspawn
On Dec 10, Marc Haber wrote: > 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? I am not familiar with debspawn, but looks like this should help: #!/bin/sh -e C_NAME=$1 if [ -z "$C_NAME" ]; then echo "Usage: $0 NAME" fi C_PID="$(machinectl show --property=Leader --value $C_NAME)" [ "$C_PID" ] || exit 1 kill -0 $C_PID || exit 2 exec nsenter \ --mount --uts --ipc --net --pid --cgroup \ --target $C_PID $SHELL -- ciao, Marco signature.asc Description: PGP signature
Re: merged-/usr transition: debconf or not?
On Nov 18, Zack Weinberg wrote: > Are you seriously claiming that that phenomenon is not a severity:critical > bug? I am seriously claming that whatever you are referring to, if true, is such a contrived example that does not actually happen in real life (or at least, it does not happen frequently enough). -- ciao, Marco signature.asc Description: PGP signature
Re: merged-/usr transition: debconf or not?
On Nov 18, Zack Weinberg wrote: > And, as it has proven to be a genuinely critical problem, it is also their No, it has not. -- ciao, Marco signature.asc Description: PGP signature
Re: merged-/usr transition: debconf or not?
On Nov 10, Sam Hartman wrote: > I'm sorry, but I think the only way in which that horse is dead is that > no one has proposed patches to dpkg. Indeed, because the sides of this argument are like three people (one of them being the dpkg maintainer) versus everybody else. Since some significant work on dpkg is reasonably not forthcoming then this is clearly not a viable transition method. -- ciao, Marco signature.asc Description: PGP signature
Re: merged-/usr transition: debconf or not?
On Nov 08, Simon Richter wrote: > Yes, but the conversion needs to be performed by dpkg, because the usrmerge Please kindly stop beating this long-dead horse. -- ciao, Marco signature.asc Description: PGP signature
Re: merged-/usr transition: debconf or not?
On Nov 08, Simon Richter wrote: > Right now, it is sufficient to preseed debconf to disallow the usrmerge > package messing with the filesystem tree outside dpkg. Managed installations > usually have a ready-made method to do so. This is not really relevant, since the conversion is mandatory. The CTTE stated that the only exception is "Testing and QA systems should be able to avoid this transition, but if they do, they cannot be upgraded beyond Debian 12", and my plan is to arrange for this with a flag file. -- ciao, Marco signature.asc Description: PGP signature
merged-/usr transition: debconf or not?
I have been asked to remove from the usrmerge package the debconf question which asks to confirm the conversion. Does anybody REALLY believe that it should not be removed? -- ciao, Marco signature.asc Description: PGP signature
Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
On Oct 18, Sean Whitton wrote:
Thank you: this is great work and, even if it requires maintaining
support for unmerged systems for yet another release, I fully agree with
the results.
> - Debian contributors who are interested in merged-/usr are invited to
> implement a straightforward migration path from non-merged-/usr to
> merged-/usr. The Technical Committee will not design this migration
> path in detail. If disputes arise related to this migration path, or
> if advice on this migration path is requested, we will resolve those
> by following our usual procedures.
>
> + One example of a migration path that might be used is for an
> Essential package to add a dependency on the usrmerge package, so
> that it will be installed automatically during upgrades. We do not
> require this to be the migration path that is chosen; it is
> presented here merely to demonstrate that such a migration path
> can exist.
This looks like a good plan. I am not sure that alternative ones
which fit the other requirements have ever been proposed, but I would
still like to hear about them if anybody has better ideas.
This is a rough sketch of a possible solution:
Package: foo
Essential: yes
Depends: usrmerge | usr-is-merged
Source: usrmerge
Package: usrmerge
Provides: usr-is-merged
Source: usrmerge
Package: usr-is-merged
Description: this is an empty transitional package
It can be removed as soon as no other package depends on it.
.
It fails in preinst if /{bin,sbin,lib*} are not a symlink.
.
It is useful to satisfy the dependency without bloating already
converted systems.
An open question: how do we make debootstrap and its clones install
usr-is-merged instead of usrmerge?
So, who is willing to be the maintainer of "foo"?
There are not too many candidates:
grep-available -s Package -F Essential yes | uniq | less
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: gbp vs. vcswatch - how to create automatic debian tags?
On Oct 05, John Paul Adrian Glaubitz wrote: > Could anyone tell me what the proper gbp command is for creating the changelog This works for me. md:~ $ cat ~/bin/git-debtag #!/bin/sh -e VER="$(dpkg-parsechangelog --show-field Version)" if [ -z "$VER" ]; then echo "Could not parse the changelog!" >&2 exit 1 fi # mangle the Debian version number as required by git conventions VER="$(echo "$VER" | sed -e 's/~/_/g' -e 's/:/%/g')" if dpkg-parsechangelog --show-field Version | egrep -q -- '-[0-9]+$'; then TAG="debian/$VER" else TAG="v$VER" fi export GIT_COMMITTER_DATE="$(dpkg-parsechangelog --show-field Date)" exec git tag -s -m "version $VER" $TAG $1 -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#995189: RFH: isc-dhcp
On Sep 28, Noah Meyerhans wrote: Should it be mentioned what the new recommended DHCP server for general use will be? > 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. > If we keep the ifup/ifdown commands > from ifupdown at all, I think they should be fairly this wrappers around > their networkd equivalents. This should be quite easy. > I don't think we should install something > like netplan by default. I agree: it only adds complexity. > (Of course, this conversation may already be taking place, but if so > I've missed it. Please feel free to point me in the right direction.) No, I think that we did not have this flamewar yet. -- ciao, Marco signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
On Sep 27, John Paul Adrian Glaubitz wrote: > Not for me, though. Debian has always followed the philosophy to be a > universal > operating system, which also meant that we can't (immediately) use all the new > technologies and features that other distributions or upstream projects > develop. It never meant that. -- ciao, Marco signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
On Sep 24, Marc Haber wrote: > 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. And the preseeding syntax is as powerful as it is inconvenient. I had not heard of growlight before yesterday, but from what I have read I think that it is very promising. Implementing support for more partition formats, if missing, should be rather easy. But which ones do we need for architectures which are not actually dead? -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#969631: can base-passwd provide the user _apt?
On Aug 29, Colin Watson wrote: > I can see the issue there. Adding another prompt that every Debian user > will need to consider on upgrade to the next release is pretty > undesirable, though - I actively try to avoid that in base-passwd > changes. So maybe the policy violation, i.e. ending up with an > inconsistent _apt UID on upgraded systems, is in fact the better option? Ys. -- ciao, Marco signature.asc Description: PGP signature
Re: merged /usr vs. symlink farms
On Aug 26, Guillem Jover wrote: > By my definition, these have never been working correctly, but > semantics I guess. It is not semantics. You keep saying that countless Debian and Ubuntu systems are not working correctly, but since this obviously does not reflect the experience of the owners of these systems then just about everybody will believe that you are wrong about merged-/usr. -- ciao, Marco signature.asc Description: PGP signature
