respect Linux capabilities(7) in cache (proxy PR)

[saschalucas]

The default GNU tar configuration does not carry fancy extended
attributes and that is where, among other things, stuff like Linux
capabilities(7) are stored. This is kind of important because that's
how ping(8) works for regular users.

We shove --selinux and --acls in there while we're at it, because why
not. We never know what the future might bring, and it seems
silly not to create a complete archive.

Note that --xattrs-include='*' is important because, by default, GNU
tar will not include capabilities /even/ if --xattrs is specified on
the commandline, see this bug report for details:

https://bugzilla.redhat.com/show_bug.cgi?id=771927

original author: Antoine Beaupré anarcat@debian.org

[saschalucas]

this is a proxy PR for #6

[anarcat]

this is a proxy PR for #6

original author: Antoine Beaupré anarcat@debian.org

I hereby relinquish all copyright ownership of this patch for now and eternity to whoever can get the patch committed in the ganeti source code.

While I fundamentally object to CLAs as an opensource project practice, in this specific case I would sign it if it wouldn't require me to sign up with Google, which I also fundamentally object to for privacy reasons. I would budge on the former, but I will not budge on the latter.

Hopefully the above first disclaimer will work around this conundrum.

Thanks @saschalucas !

[anarcat]

I'll also note that this fix was uploaded in Debian unstable in bug 896508 and proposed as an stable update in bug 944538 although the latter hasn't been accepted yet. The main technical complaint about the patch in the latter bug was this:

I'm a bit uneasy about a blanket "include all", to be honest. It's
probably harmless since it's all coming straight out of debootstrap, but
I'd have been happier with something like "include security.*" if that's
what we expect to see.

I don't agree with the analysis: I can't see what's wrong with "include all" in the first place, but I thought it was useful to bring it up here.

[iustin]

@saschalucas: I'm not sure how this skips the need for the original author to sign the CLA. The fact you created this pull request is besides the point, what matters is that the original author gives the right blah blah blah.

@anarcat: ack, and I'm sorry that the CLA requires one to have a google account.

IMHO what should happen here:

• the project completes the move from Google to SPI, as discussed in other forums
• the CLA requirement is either completely waved (not so good IMHO, but that's beside the point), or the CLA check is changed to become much more simple
• and then the original patch can go in, with @anarcat 's email address.

So, all it means is that this has to stay uncommited for a few more weeks (? 1-2 months?), which is not a problem as the code is out there and any downstream or user can apply this patch.

[anarcat]

@saschalucas: I'm not sure how this skips the need for the original author to sign the CLA. The fact you created this pull request is besides the point, what matters is that the original author gives the right blah blah blah.

seriously... it's a two-line patch...

CLAs are a bit absurd in the first place, requiring them for such small changes seem even more absurd. :)

So, all it means is that this has to stay uncommited for a few more weeks (? 1-2 months?), which is not a problem as the code is out there and any downstream or user can apply this patch.

it's been months now. has the project moved to SPI just yet?

is there still a google-bound CLA?

btw, i strongly mind the google requirement for the CLA, but I also do mind having a CLA in the first place. i think you should remove as much friction as possible to contributions in a project. I also doubt that a CLA has strong legal protections: the "license in, license out" jurisprudence (which is presumably why you want a CLA in the first place, given that this is GPL), is at least as well established as the CLA legalities. for me it's definitely not worth the tradeoff.

if you really, really need some sort of CLA, you could use some lighter version like the DCO that's used by the Linux Kernel, gitlab, git, docker and many others.

obviously, this is probably not the right forum to discuss this, but I don't exactly know where to go for this, so i figured i'd raise this again at the very least. because right now we're in this very weird situation where there is a trivial patch -- with basically no "original" or "copyrightable" content in it -- that is stuck in this queue and can't be merged (even if written by a CLA-abiding contributors).

that's kind of a shame. :)

[anarcat]

this weird situation made me think of writing a longer reflexion of the problem of non-consenting CLA contributors, which I think you should also think about if you're going to reconsider the CLA: the CLA Denial-of-Service attack.

(Note that this is not a DOS: I am honestly against signing a CLA using a Google account. I don't want to mess with the Ganeti project, and I genuinely want to contribute. It just the mechanics are too annoying right now.)

[geor-g]

@anarcat Thanks for your messages, and your work. I fully agree, and would be very happy to see the transfer to SPI happening soon, in case that's not done, yet. In case there is specific support needed in this direction, let me know.

[anarcat]

SPI has now accepted ganeti, can we have a go on this? :)

http://lists.spi-inc.org/pipermail/spi-general/2020-April/004075.html

[saschalucas]

Dear @anarcat,

you are right, SPI has accepted Ganeti to become an associated project. Unfortunately we are not done now. Next step is, to transfer the project from Google to SPI, before we can drop the CLA. So I'm asking kindly to stay patient ...

[atta]

LGTM - the change is in Debian for some time now so merge it upstream.

https://salsa.debian.org/ganeti-team/ganeti-instance-debootstrap/-/blob/master/debian/patches/respect-Linux-capabilities-7-in-cache.patch