shadow: update to 4.15.0.

[dataCobra]

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, (x86_64-glibc)
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • x86_64-musl
  • i686

I welcome everyone to test this version. Maybe also on a new installation.

[dataCobra]

The file /etc/default/useradd is no longer created by default. Instead now the patched useradd binary is aware of the defaults that we provided before with the old version in /etc/default/useradd.

[dkwo]

Some distros are also carrying this patch https://git.alpinelinux.org/aports/tree/community/shadow/fix-undefined-reference.patch Maybe it's useful?

[dkwo]

As a reference, /usr/bin/lastlog and its manpage are now gone, and there are new /usr/bin/getsubids and its manpage

[dkwo]

also the file login.defs seems outdated. distros like arch and chimera patch it instead of replacing it.

[dataCobra]

Some distros are also carrying this patch https://git.alpinelinux.org/aports/tree/community/shadow/fix-undefined-reference.patch Maybe it's useful?

I've added the patch and everything still builds fine.

As a reference, /usr/bin/lastlog and its manpage are now gone, and there are new /usr/bin/getsubids and its manpage

Forgot to add the new configuration argument to add lastlog. Fixed with the new push.

also the file login.defs seems outdated. distros like arch and chimera patch it instead of replacing it.

I've checked what Arch did and added and modified patch 2 and 3 so they fit our needs. The file will now be installed from shadow itself and patched beforehand. I removed the fixed file we provided.

[dkwo]

about the patches from arch linux: they may need more adaptating to our needs. for example, yescrypt needs a build option if i remember right.

[dataCobra]

I've added yescrypt to be build for shadow to make sure we got a secure password hash.

[dataCobra]

CC: @Gottox

Could you as a maintainer please check this as well? :slightly_smiling_face:

[dkwo]

what is the reason for removing xstrdup.patch instead of updating it?

[dataCobra]

what is the reason for removing xstrdup.patch instead of updating it?

What do you want to update?

The function does no longer exist and the file is also removed.

In lib/alloc.c a comment says:

/* Replacements for malloc and strdup with error checking.  Too trivial
   to be worth copyrighting :-).  I did that because a lot of code used
   malloc and strdup without checking for NULL pointer, and I like some
   message better than a core dump...  --marekm

   Yeh, but.  Remember that bailing out might leave the system in some
   bizarre state.  You really want to put in error checking, then add
   some back-out failure recovery code. -- jfh */

As I understand the patch is no longer needed.

[dkwo]

see https://github.com/chimera-linux/cports/blob/master/main/shadow/patches/xstrdup.patch

[dataCobra]

see https://github.com/chimera-linux/cports/blob/master/main/shadow/patches/xstrdup.patch

Thank you for the link.

[dkwo]

• does it make sense to disable RUSEROK for all libc through a patch, instead of selectively in pre_configure?
• same for groups(1): instead of in do_build, can this be done in a patch?
• is the use of a license file still needed?
• i think we should have only one patch for login.defs, which can be void-specific

[dkwo]

e.g. see https://gitlab.archlinux.org/archlinux/packaging/packages/shadow/-/blob/main/0001-Disable-replaced-tools-their-man-pages-and-PAM-integ.patch?ref_type=heads and https://github.com/chimera-linux/cports/blob/master/main/shadow/patches/disable-ruserok.patch

[dataCobra]

• does it make sense to disable RUSEROK for all libc through a patch, instead of selectively in pre_configure?

I've added the patch you recommended from chimera linux.

• same for groups(1): instead of in do_build, can this be done in a patch?

We could do that in a patch, but I feel like the way in the template is more convenient and easier to update.

• is the use of a license file still needed?

I'll check that.

• i think we should have only one patch for login.defs, which can be void-specific

Agree. For the moment I've only modified the patches a bit. But refactoring and cleaning up the files in the patches folder after we've finished the decision which patches to include must be done. Otherwise it might be hard to update the package in the future.

[dkwo]

We could do that in a patch, but I feel like the way in the template is more convenient and easier to update.

alternatively, could it be moved to either post_configure or pre_build?

[dkwo]

btw, 4.14.6 is out, soon maybe 4.15

[alejandro-colomar]

Some distros are also carrying this patch https://git.alpinelinux.org/aports/tree/community/shadow/fix-undefined-reference.patch Maybe it's useful?

That patch shouldn't be necesary. Please don't apply it unless you find a reason to. And if you do (find a build error that requires the patch), please report it as an upstream bug.

Would you mind asking the Alpine maintainer if they can comment on that patch? I'm interested in fixing upstream if there's something broken, but I'd like to learn what's broken, because that patch looks like a red herring.

[dkwo]

@alejandro-colomar Thanks a lot for taking a look. Do you think it would be possible to make stuff that conflicts with coreutils and util-linux (e.g. groups) optional via a configure? right now most distros have to patch it (and their man) out (see the patch taken from arch). Ditto for respecting usr/bin and usr/sbin config options.

For the Alpine patch, maybe can you take a look at this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50121 pull request? the first thread has a discussion about why this was done.

[alejandro-colomar]

Hi!

@alejandro-colomar Thanks a lot for taking a look.

=)

Do you think it would be possible to make stuff that conflicts with coreutils and util-linux (e.g. groups) optional via a configure?

I'm neutral to that, but others seem to not like the idea. (Now I see you're the same one that reported the issue https://github.com/shadow-maint/shadow/issues/842.) How about opening an issue, not asking to make it conditional, but rather reporting the conflict with other projects? Maybe that's more convincing. You could document which distros use shadow's groups, and which distros use others' groups. Maybe we could merge the efforts from those other projects and shadow into a single groups implementation. While some competition is good, it might be good to merge at some point.

right now most distros have to patch it (and their man) out (see the patch taken from arch). Ditto for respecting usr/bin and usr/sbin config options.

You know what? I would wipe out the entire autotools-based build system, which has been more problematic than anything else. I would write a hand-written GNUmakefile that allows more flexibility. But some distro maintainers (cough, Gentoo, cough) opposed strongly.

Please, please, report a bug in shadow. That will add up to the current issues with the build system. :)

For the Alpine patch, maybe can you take a look at this https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50121 pull request? the first thread has a discussion about why this was done.

Yup, I found that MR a moment ago, and sent an email https://lists.sr.ht/~hallyn/shadow/%3CZeyg8ClVMNeRifua%40debian%3E, https://lists.alpinelinux.org/~alpine/aports/%3CZeyg8ClVMNeRifua%40debian%3E.

[dataCobra]

Thank you both for all the input and information.

I'm currently working on an update to 4.15.0.

[dkwo]

it may also be possible to drop the ruserok patch

[alejandro-colomar]

it may also be possible to drop the ruserok patch

If you investigate that ruserok thing, you may want to have fun upstream with the "quick hack":

https://github.com/shadow-maint/shadow/blob/ead55e9ba8958504e23e29545f90c4dd925c7462/configure.ac#L162 https://github.com/shadow-maint/shadow/commit/428a2078b6c435f1780ec8f381033e7bd937d29e https://github.com/shadow-maint/shadow/commit/45c6603cc86c5881b00ac40e0f9fe548c30ff6be#diff-bb21aa33a3f69ccb36c68b220f40ad08f29b9cd2c05dfedae7b9e3d5d4d08f6bR196

:)

[dataCobra]

@Gottox are you able to help as the maintainer of the package?

If you have some more knowledge/information.