[Dev] libretools 20140106 release announcement

[Luke T. Shumaker]

At Tue, 07 Jan 2014 22:59:52 -0500,
Luke T. Shumaker wrote:
> 
> At Sun, 05 Jan 2014 23:28:47 -0500,
> Luke T. Shumaker wrote:
> > I just pushed libretools 20140106.1 to [libre].  It has a couple of
> > exciting new features.  Be sure to merge your .pacnew files!
> ...
> > Other changes from 20131112 to 20140106:
> ...
> >  * libremakepkg:
> >     * bugfix: can now build bzr packages with `-N` (don't do this)
> >     * feature: can now build `make --(all)source` files
> 
> After speaking with André on IRC, this seems to have introduced some
> issues.  We're both totally perplexed, but downgrading seems to fix it
> for him.  I can't replicate it, which makes debugging it hard, but
> both he and Márcio are experiencing it, so I'm accepting that it is a
> bug.

To follow up on this,

The release also fixed a couple of independent bugs in libremakepkg
that I didn't even realize were there, or that I accidentally fixed
them, until I started digging into this.  The bugs were colluding
together to do the wrong thing, but in a way that worked--any one of
them were fixed, but not all of them, it would stop working.

The issue now is that users experiencing the problem have restrictive
umasks/FACLs on their files, so when makepkg is running as `nobody` in
the chroot, it doesn't have permission to read the source files.  The
reason they didn't experience this before is that because of the bugs,
things were getting "needlessly" `cp`ed around as `root`, so when
`nobody` eventually had to read them, the file permissions were OK, as
the umask had been set to 022 before copying them.

Now the question is what to do about it.  Options:

 1. Undo the bugfixes
    Pros:
     - Will work correctly in all cases
     - Won't do anything unexpected, from the users' point of view
    Cons:
     - Will require me to maintain a backport of re-introducing bugs
       into devtools
     - The extra `cp` take more time and put more load on the HDD
 2. Add a check to make sure the file permissions are OK, and bail if
    they aren't.
    Pros:
     - Simple
    Cons:
     - Clear reduction of functionality
     - Pain for existing users to transition
     - Basically mandates a lenient umask, bad for security
 3. `chmod` the necessary files, bail if ACLs are still to
    restrictive
    Pros:
     - Simpler than next option
     - Fixes most common cases
     - Saying 'tune the FACLs for X directory' is less invasive than
       'set your umask differently'
    Cons:
     - Still a reduction in functionality
     - Changes file permissions behind the user's back
 4. `chmod` the necessary files, set FACL 'u:nobody:r' (rx for
    directories)  if they still can't be read.
    Pros:
     - No reduction in functionality/will work correctly in all cases
    Cons:
     - Changes file permissions behind the user's back
     - Changes FACLs behind the user's back
     - Potentially clutters the FACL
     - Most complex option
 5. `chmod` the necessary files, remove FACL on them if the FACL is too
    restrictive.
    Pros:
     - No reduction in functionality/will work correctly in all cases
    Cons:
     - Changes file permissions behind the user's back
     - *REMOVES* the FACLs behind the user's back

FACLs have the potential to be very complex.  Setting 'u:nobody:r[x]'
will give the permissions it needs, but blindly adding to the FACL
feels... dirty.   I'm tempted to say "It will take care of the Unix
file permissions, but only check for the FACLs. Setting the FACLs
correctly is on the user." (option 3), but that's still a reduction in
functionality.

Happy hacking,
~ Luke Shumaker