search

shadow-maint / shadow

Upstream shadow tree
Other
304 stars 232 forks source link

4.15 release #923

Closed hallyn closed 7 months ago

hallyn commented 9 months ago

I'm thinking of cutting a 4.15(-rc1) release. Please comment here if there are specific PRs or issues which should be addressed first.

alejandro-colomar commented 9 months ago

Rationale: These fix soon-to-be compiler errors. If we fix them now, the 4.15 release series will see less build error reports. It's a preparation for GCC 14 and Clang 16, which become more aggressive regarding compiler errors.

CC: @thesamesam

alejandro-colomar commented 9 months ago

Rationale: I'll be backporting those to 4.14.4. It would be better if 4.15 has them without a backport.

alejandro-colomar commented 9 months ago

Rationale: It contains a typo fix that fixes incorrect CFLAGS in some tests. I expect that systems with pedantic build rules, like Gentoo, might have build problems without it.

ikerexxe commented 9 months ago

Good to see that we have a list. I'll try to dedicate some time in the following days to review those PRs.

By the way, I may have a PR also, but I haven't posted it yet. If I have time it should go to 4.15, if not, well, it'll go to the next one.

hallyn commented 9 months ago

Thanks!

ikerexxe commented 9 months ago

This is the PR that I was talking about https://github.com/shadow-maint/shadow/pull/927. Only in the end I didn't implement it myself.

alejandro-colomar commented 8 months ago

I would leave #927 for after the cut. Being a new feature, I'd give it some more time for discussion.

ikerexxe commented 8 months ago

I would leave #927 for after the cut. Being a new feature, I'd give it some more time for discussion.

I'm fine with delaying it a little bit, but I'd like to see this one (or a similar approach) merged.

alejandro-colomar commented 8 months ago

I would leave #927 for after the cut. Being a new feature, I'd give it some more time for discussion.

I'm fine with delaying it a little bit, but I'd like to see this one (or a similar approach) merged.

It seems Tobias doesn't have concerns anymore, and to me, the code looks simple. So, for me it's ok.

stoeckmann commented 8 months ago

It seems Tobias doesn't have concerns anymore, and to me, the code looks simple. So, for me it's ok.

Correct. I was just curious why a feature is added if another program already has it. But then I noticed the : issue with newusers, so there is clearly no objection anymore from my side.

hallyn commented 8 months ago

Ok - I think everything is merged now, so we should be ready for a 4.15-pre1?

ikerexxe commented 8 months ago

Yes, it looks like everything is ready, at least from my side.

alejandro-colomar commented 8 months ago

On Thu, Feb 01, 2024 at 12:05:57AM -0800, Iker Pedrosa wrote:

Yes, it looks like everything is ready, at least from my side.

Me too. I'm also ready for 4.14.4.

-- https://www.alejandro-colomar.es/ Looking for a remote C programming job at the moment.

alejandro-colomar commented 8 months ago

I'll reopen this to list things before an rc2.

I'd like to see

and after Michael reported some bug to me, I'm thinking that the following would also be necessary before looking into fixing that one:

Cc: @jubalh

jubalh commented 8 months ago

I opened https://github.com/shadow-maint/shadow/issues/939 now for the bug. I didn't yet have time to check it more deeply but thought since we are short before a new stable release it might be time to fix it.

ikerexxe commented 8 months ago

I had time today to try to build 4.15.0-rc1 and it looks good on my end. Unfortunately I can't push it to Fedora rawhide (what will become Fedora 40) because we are dealing with the provision of passwd binary from shadow and I'd like to give some time for things to settle before rebasing. I'll try to do that next week, once more automated tests are run and some people test that the change is working properly.

hallyn commented 8 months ago

@ikerexxe sorry what do you mean by "the provision of passwd binary"?

hallyn commented 8 months ago

I think I've merged everything needed for -rc1. Are we missing anything else?

alejandro-colomar commented 8 months ago

Before the release, we should probably fix https://github.com/shadow-maint/shadow/issues/945. But since there are no patches for it yet, I think we're ready for -rc2.

alejandro-colomar commented 8 months ago

Maybe the Georgian translation?

ikerexxe commented 8 months ago

@ikerexxe sorry what do you mean by "the provision of passwd binary"?

Fedora was using a passwd binary provided by the passwd package. We've changed that recently, and now we are using shadow's passwd. We need some time to run all tests before I can rebase shadow to 4.15.0.

alejandro-colomar commented 8 months ago
ikerexxe commented 8 months ago

Hi @hallyn,

You haven't signed 4.15.0-rc2 :S

gpg -v shadow-4.15.0-rc2.tar.xz.asc 
gpg: enabled compatibility flags:
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: assuming signed data in 'shadow-4.15.0-rc2.tar.xz'
gpg: Signature made vie 16 feb 2024 01:07:14 CET
gpg:                using RSA key 7E56E2C13FA77CE31559ADC97DC24C36C3341D20
gpg: Can't check signature: No public key
alejandro-colomar commented 8 months ago

Hi @hallyn,

You haven't signed 4.15.0-rc2 :S

Hi @hallyn,

If this is maybe a new (sub)key, maybe you forgot to push it to the keyserver?

$ gpg --verify shadow-4.15.0-rc1.tar.xz{.asc,}
gpg: Signature made Fri Feb 16 00:27:47 2024 CET
gpg:                using RSA key 7E56E2C13FA77CE31559ADC97DC24C36C3341D20
gpg: Can't check signature: No public key
$ gpg --recv-keys 7E56E2C13FA77CE31559ADC97DC24C36C3341D20
gpg: keyserver receive failed: No data
hallyn commented 8 months ago

Jinkeys! gpg is not treating me right. That is not how that subkey was supposed to be created+used.

hallyn commented 8 months ago

@alejandro-colomar could you try again now? I pushed to ubuntu, not sure what keyservers the cool kids are using these days.

alejandro-colomar commented 8 months ago

@alejandro-colomar could you try again now? I pushed to ubuntu, not sure what keyservers the cool kids are using these days.

I had similar problems a couple of weeks ago. I created my new subkey, and pushed to the default keyserver, but other people reported that my key wasn't in the keyservers. The ubuntu keyserver also had a few errors with my new subkey back then:

$ gpg --keyserver keyserver.ubuntu.com --recv-keys D57633D441E25BB5
gpg: keyserver receive failed: Server indicated a failure

(the above happened on Sun, 4 Feb 2024)

@alejandro-colomar could you try again now?

With the default keyserver, I still can't get it. But the ubuntu keyserver succeeded:

alx@debian:~$ gpg --list-key --keyid-format 0xlong hallyn
pub   rsa2048/0xB175CFA98F192AF2 2012-05-07 [SC]
      66D0387DB85D320F8408166DB175CFA98F192AF2
uid                   [  full  ] Serge Hallyn <sergeh@kernel.org>
uid                   [  full  ] Serge Hallyn (kernel.org) <serge@hallyn.com>
sub   rsa2048/0x993087AF1E967E77 2019-10-20 [A]
sub   rsa2048/0x345007B943143245 2019-10-20 [E]
sub   rsa2048/0x3570DA17270ACE24 2019-10-20 [S]
sub   rsa2048/0xD62F64D09CDDF031 2012-05-07 [E]

pub   rsa2048/0xE9FEEA06A85E3F9D 2010-06-07 [SC]
      F1D08DB778185BF784002DFFE9FEEA06A85E3F9D
uid                   [  full  ] Serge Hallyn <serge.hallyn@ubuntu.com>
sub   rsa2048/0xC527609C7E1875BD 2010-06-07 [E]

alx@debian:~$ gpg --recv-keys --keyserver keyserver.ubuntu.com 66D0387DB85D320F8408166DB175CFA98F192AF2
gpg: key B175CFA98F192AF2: "Serge Hallyn <sergeh@kernel.org>" 1 new signature
gpg: key B175CFA98F192AF2: "Serge Hallyn <sergeh@kernel.org>" 1 new subkey
gpg: Total number processed: 1
gpg:            new subkeys: 1
gpg:         new signatures: 1
alx@debian:~$ gpg --recv-keys --keyserver keyserver.ubuntu.com F1D08DB778185BF784002DFFE9FEEA06A85E3F9D
gpg: key E9FEEA06A85E3F9D: "Serge Hallyn <serge.hallyn@ubuntu.com>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

So now:

alx@debian:~$ gpg --list-key --keyid-format 0xlong hallyn
pub   rsa2048/0xB175CFA98F192AF2 2012-05-07 [SC]
      66D0387DB85D320F8408166DB175CFA98F192AF2
uid                   [  full  ] Serge Hallyn <sergeh@kernel.org>
uid                   [  full  ] Serge Hallyn (kernel.org) <serge@hallyn.com>
sub   rsa2048/0x993087AF1E967E77 2019-10-20 [A]
sub   rsa2048/0x345007B943143245 2019-10-20 [E]
sub   rsa2048/0x3570DA17270ACE24 2019-10-20 [S]
sub   rsa2048/0xD62F64D09CDDF031 2012-05-07 [E]
sub   rsa4096/0x7DC24C36C3341D20 2024-02-04 [S]

pub   rsa2048/0xE9FEEA06A85E3F9D 2010-06-07 [SC]
      F1D08DB778185BF784002DFFE9FEEA06A85E3F9D
uid                   [  full  ] Serge Hallyn <serge.hallyn@ubuntu.com>
sub   rsa2048/0xC527609C7E1875BD 2010-06-07 [E]
hallyn commented 8 months ago

With the default keyserver, I still can't get it. But the ubuntu keyserver succeeded:

Which is your default keyserver? I'll push it to there, double my chances :)

alejandro-colomar commented 8 months ago

With the default keyserver, I still can't get it. But the ubuntu keyserver succeeded:

Which is your default keyserver? I'll push it to there, double my chances :)

Whatever the default is, as I tend to not change defaults as much as I can. However, that keyserver seems to be failing more often than not, so I may change it for the ubuntu one some day (that one also proved to fail, but less often)...

It seems to be using hkps://keys.openpgp.org when I don't specify one.

hallyn commented 8 months ago

Ok, I've pushed it to keys.openpgp.org as well.

fwiw the reason I created this subkey was because something was upset that my signing keys were not rsa4096. So this gives me a bigger, hardware-bound signing subkey. FTW I guess.

alejandro-colomar commented 8 months ago

This is the only remaining thing, I think:

Cc: @firasuke, @awilfox

firasuke commented 8 months ago

This is the only remaining thing, I think:

* [login and logoutd broken on systems with utmps #945](https://github.com/shadow-maint/shadow/issues/945)

Cc: @firasuke, @awilfox

Perhaps this can be reverted. Or maybe have utmpx unconditionally available?

It would be even better if utmps was supported (being a secure implementation for musl based distros), in case you didn't want to bring the entirety of utmp.

alejandro-colomar commented 8 months ago
alejandro-colomar commented 8 months ago
firasuke commented 8 months ago

@alejandro-colomar It appears that #945 has been solved. Are there any other issues before the release of 4.15?

alejandro-colomar commented 8 months ago

@alejandro-colomar It appears that #945 has been solved. Are there any other issues before the release of 4.15?

No. But @hallyn will do that release, not me. I only release from stable branches (currently, 4.14.x).

I plan to release 4.14.6 on 2024-03-02 (my birthday :). Maybe it would be a good idea to release 4.15 after that, as we will get a little bit more testing for these recent bug fixes, some of which are present in the stable branch. Serge, what are your plans? Maybe an -rc around the release of 4.14.6, and then 4.15.0 a few days later?

hallyn commented 8 months ago

I'm just waiting for some go/no-gos from distro maintainers. If all's good, I'm happy to tag final 4.15.

hallyn commented 8 months ago

I see - more has been merged into master since 4.15.0-rc2 than I thought. I can tag -rc3 around march 3 as @alejandro-colomar suggested, or i can tag one now if someone wants to test, and then tag an rc-4 in a week.

alejandro-colomar commented 8 months ago

Well, if you want to -rc3 already... I don't expect anything else to go in, unless there are new bug reports, so maybe that helps.

alejandro-colomar commented 7 months ago

and then tag an rc-4 in a week.

This Friday ends that week. Since/if nothing seems to be problematic, should we release final 4.15.0 on Friday?

ikerexxe commented 7 months ago

I think that is phenomenal.

alejandro-colomar commented 7 months ago

BTW, there seems to be a release draft called Draft. Is that a leftover?

hallyn commented 7 months ago

Yes, let's release 4.15.0 on Friday.

yeah, the draft release was the first of the series which i had posted. I was sure I had published it, and when I noticed it sometime last week it still resisted being published... should probably delete it.

alejandro-colomar commented 7 months ago