Wrong group assumptions in `test_make_cred`

[brvtalcake]

Describe the bug
When trying to install from AUR, the test test_make_cred failed at line 535 (which is still there in the main branch).

To Reproduce
Steps to reproduce the behaviour:

1. Login as any user or switch user (on my system I did su pkg-builder)
2. Log into / switch to a different group than the main user's group (on my system again, I did sg system-update, which I created as a standalone group, but the behaviour should be the same with any group as far as its GID is different from user's corresponding group's)
3. Install from the AUR (in my case paru -Syu dosr). It seems to install v3.2.4-1. In my case I gave the system-update group permission to run sudo --user=root pacman ..., which is usually ran by pacman wrappers (i.e. I basically tried to implement some basic kind of RBAC myself)
4. Paru should run the tests (at least by default, I suppose, since I didn't change anything) and you should see the error

Expected behaviour
I'm pretty sure this assert_eq! should not exist ? At least not in distributed code ?

Desktop (please complete the following information):
Not a desktop but (arch-)chrooted Arch from Arch LiveCD (but otherwise any OS with GIDs) through ssh while trying to setup my VPS. Not really relevant, anyways, though.

Additional context
I just hope the project doesn't rely on such assumption in its crucial parts ?

PS : I apologize beforehand if I later do not reply. I tend to have very little motivation and attention spans 😬 (and that would have nothing to do with me not wanting to talk to god-knows-who)

[LeChatP]

Thanks a lot for the issue!

Yes, these tests are mainly meant to ensure that credential gathering does not panic and returns something valid, so this check is unnecessarily strict and leads to false negatives.

More-or-less related to this part of code, v4.0.0 also handles the case where /etc/group not present in the system. Not sure why or how this would happen, but Rust made it obvious this needs to be handled. And for the /etc/passwd file, we just can't do without it. It must be present on the system... Sorry if the rm -rf /etc command went wrong...

Now I'm thinking about other assumptions, and I found one : During the current setgid handling: the first group specified is used for setgid(), and is also placed first in setgroups() (while there is no guarantee about the order), with the remaining groups following.
This matches how -g works in ogsudo, and what we had in RootAsRole back in the 2019 C version. POSIX doesn't enforce any relationship between the effective GID and supplementary groups, so they could technically be decoupled. I guess ogsudo does it this way either for simplicity or to keep the primary group visible in the supplementary list. In both cases, I don't see anything wrong with it.

Edit with a conclusion: So, I'll remove this assert.