[Reproducible-builds] Remaining reprotest variations

[Jérémy Bobbio]

Ceridwen:
> For most of the variations I've done so far, I've been either
> depending on external utilities or had POSIX-compliant ways to execute
> them.  The rest of the variations pose more problems.
> 
> 1. user_group.  The POSIX standard includes the notion of user/group
> ids, but the only ways it defines to change the uid/gid of processes
> are C functions.  Unfortunately, there's also nothing in the POSIX
> standard for creating users, though at least `chown` is.  At the
> moment, my plan is to use `useradd`, `groupadd`, `userdel`,
> `groupdel`, and `su`.  (Using 'sudo' like prebuilder does is more
> complicated and less likely to be supported everywhere.)  I'm going to
> set the ids to something like 20000.  This page,
> http://bhami.com/rosetta.html, indicates that this won't work on
> FreeBSD or MacOS X, and thatis supported by these pages,
> http://www.math.utah.edu/~beebe/unix/g/groupadd.html and
> http://www.math.utah.edu/~beebe/unix/u/useradd.html.
>     - What works on FreeBSD/MacOS X?
>     - Are there any other problems I'm likely to encounter using `su`?

If the code abstract user creation/removal depending on the system of
the execution environment, we could implement (more) specific behaviors
when required. Maybe that could be an answer: make it so experts in
other operation system can easily add support?

This applies to several variations you've listed as well, IMHO.

> 6. time: tests.reproducible-builds.org sets the system clock into the
> future for some machines, which doesn't work here.  I can try to use
> libfaketime for non-qemu environments and make the VM clock
> independent for qemu, but this is likely to get very tricky.  How much
> time should I spend on this?

We found many many problems that were related to time once all the
checks were in place, so it would be good if reprotest could have
similar support. Being able to run a different clock in qemu would be
best, I think.

> Beyond the specific variations, I have some questions about reversion
> that apply to several variations.  I'm trying to have reprotest revert
> all the changes it makes on its own, to make it more useful for
> simpler execution environments, but guaranteeing this under all
> conditions is tricky.
> 
> * If reprotest is called as root without any virtualization
>   (i.e. null), should it attempt to run the variations that require
>   root privileges on the host system?  These are host, domain, bin_sh,
>   and user_group.  I'm reluctant to disable this functionality
>   altogether, because I can see someone wanting it, but it definitely
>   has the potential to cause undesirable side effects if something
>   goes wrong.
>
> * Along the same line, `chsh` affects all user shells.  This doesn't
>   require root privileges, but should it be tested without
>   virtualization?

I think we should mandate isolated environment for anything that could
make the system go wrong. Or require a
“--i-dont-care-if-this-system-gets-broken” extra flag. ;)

Thanks for your insightful summary! :)

-- 
Lunar                                .''`. 
lunar at debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160727/0670e136/attachment.sig>