<ivan>
I figure some of the saner routes here are cajoling upstream to disable it by default (unlikely to work because they have remote magtape protocol users somewhere?) or moving away from tar (which has a pretty ugly old codebase anyway)
<pie_>
>>>> 2005
<pie_>
if im reading that correctly
<pie_>
wow
<andi->
ivan: what drop in replacement would you hand users that behaves the same without killing UX and thus makes people cry for "real" tar again? I could see that feature being disabled by default (via the inverse feature flag). On the other hand I know one person that's using that feature... Still it is bad that is transparently behaves "weird" to the average Joe.
<ivan>
yeah, I guess you're right, reimplementing tar's ux is a lot of work, but I wonder if something fairly simple could be enough for at least the uses of tar inside nixpkgs (none of which --force-local of course)
<ivan>
of course most don't need to but there are a few suspicious ones
<andi->
The solution I could see is having a "normal" tar that has the switch flipped and another tar in nixpkgs where said patch is missing and that can be used if that (or many insecure features?) are explicitly used.
<andi->
I am not usre how the user acceptance towards that would be. My guess is that not many people would realize that our (default) tar is different.
<andi->
Did you hunt on the upstream MLs, other distros bug trackers, ... how they handle that case?
<andi->
IMO is it the old (and classic) fight of having to find a nice path between RTFM and "safety as default".
<andi->
rm -rf . is also a dangerous command if you don't know that it does.
<ivan>
I'm guessing no one handles it
<ivan>
but I'll look around
<ivan>
tar NEWS entry from 1992
<ivan>
* Remote archive names no longer have to be in /dev: any file with a
<ivan>
':' is interpreted as remote. If new option --force-local is given,
<ivan>
then even archive files with a ':' are considered local.
<andi->
yay, anti-features that probably looked awesome back then :D
<andi->
thinking about it we should probably make --force-local a noop
<andi->
a bit off-topic: windows-users seem to use tar quiet often with colons (X:\..) the ML archive has a few of those but so far no discussions regarding changing it :/
<ivan>
I brought it up! anyway, I will write in support
<andi->
oh
<pie_>
andi-, wrong person
<pie_>
yeah lol :D
<andi->
ivan: whats your handle?
<andi->
ahh yeah, I read the >>>> 2005 line and assumed that was you.. sorry for that
<pie_>
;P
<pie_>
oh well, maybe ill be responsible for something eventually :p
<andi->
the guy from the gnutar ML seems to be a RedHat person. I left him a message on memoserv. Lets see if he reads them... maybe they also have thoughts about that.
<ivan>
andi-: @ivan
<andi->
ivan: thanks, I already "hacked" that out of your IRC nick ;)
<ivan>
heh
<andi->
I wonder, is @NixOS/security-notifications the right "user" to highlight for our offical security team? :) I would like to hear from the regarding those and particular that issue.
<ivan>
I guess you figured out that you have to keep the old option as a no-op
<ivan>
let's see if the remote magtape protocol users come crawling out of the woodworks :-)
<andi->
I am a bit uncertain what to do if both are set --force-local --allow-remote because of wrapper scripts etc..
<andi->
if we should explicitly fail then...
<ivan>
btw, I tab-completed a file with a colon as an rsync argument, and you can guess what happened next. rsync, is of course, far less of a problem being rarer and having more colon awareness
<andi->
oh stop it.. don't me me switch to plan9 or openbsd or so..
<andi->
;)
<ivan>
I feel like --force-local could just override --allow-remote (with a wording change in the help)
<ivan>
I bet I won't have a strong opinion about it though
<ivan>
after all, it's merely allowed and can be forced off, and --force-local is safer
<pie_>
sounds like a mess
<pie_>
i suppose fail fast and easily searchable error message might be good
<andi->
maybe we can add a dependency on cowsay for "good" error messages..
<ivan>
post-fixed-tar, someone with a --force-local wrapper script could just get rid of the wrapper script (assuming they're not in multi-OS-compat hell). a magtape user with an --allow-remote wrapper script could, in theory, still desire to --force-local sometimes.
<andi->
I am still trying to figure out where I saw that issue before you mentioned it here..
<ivan>
btw, that AppArmor profile I wrote didn't even work properly! I prevented tar from networking and that stopped it from being able to read files on a cifs mount.
<andi->
well nobody said AppAmor is a silver bullet that just works ;)
<andi->
right, there was this: grep] Search for "force-local" in /irc/oftc/#debian-security.weechatlog.
<andi->
2017-12-07 02:47:28 sarnold I think you'd have trouble getting a CVE assigned for this. maybe if tar upstream had a change of heart and wantedx to make --force-local the default, and require --force-remote to re-enable this feature
<pie_>
i suppose you have a good point about multi-os-compat hell
<pie_>
what would be the sanest way to accomodate that?
<pie_>
i.e. is there anytihng that would put someone in a deadlock situation
<ivan>
do you mean in the case where they want --force-local or they want --allow-remote?
<pie_>
idk im just bikeshedding, i didnt think hard at all
<pie_>
ignore me if you want
<pie_>
wow its really easy to think a lot about relatively trivial things.
<ivan>
the --allow-remote case may be annoying for a multi-OS user but they can check if they're on nixos or grep the tar options
<andi->
the discussion from #d-sec had a good point: remove the colon splitting and add a new argument for the remote host. That would be a good (upstream) fix..
<pie_>
that probably makes more sense.
<pie_>
so i guess, something that could be problematic is if someone uses tar as a dependency
<pie_>
and this takes us to the general issue, which idk how one usually tries to resolve.
<pie_>
do you just mark it insecure and wait for upstream to fix?
<ivan>
andi-: that seems less wrappable, right?
<andi->
also according to them upstream treats it as a feature so not really accepting a change there..
<ivan>
I don't know how much wrapping matters
<andi->
I would not want to introduce a wrapper that tries to make that thing saner... I'd rather nuke the feature..
<ivan>
I mean, someone may need a wrapper if they can't modify their remote magtape backup scripts for some reason
<pie_>
@ "its not a bug its a feature"
<andi->
ivan: sure, but if they are on nixos why would they have a >20y old backup script? :)
<andi->
that they can't modify!
<ivan>
maybe the solution in nixos should be good enough to get imported elsewhere. or maybe not!
<pie_>
i guess there should probably be test cases if upstream doesnt accept
<ivan>
someone could take the nixos fix and apply it to their users without as much thought
<pie_>
i.e. its basically maintaining a separate branch
<pie_>
"wat do"
<pie_>
though in the short term saying fuck it and just doing the thing wil probably work? ¯\_(ツ)_/¯
<ivan>
thought leadership in fixing 26 year old misfeatures
<pie_>
^
<pie_>
we are nixos.
<pie_>
we'll be needing to fix our own misfeatures in 20 years lol
<andi->
I am really wondering that I can't seem to find more references to things like that debian issue :/
<pie_>
might as well start now? :D
<pie_>
at least its on the issue tracker though, thats something.
<pie_>
please please never do the "issue closed due to inactivity" shit and stuff like that
<pie_>
that pisses me off so bad
<andi->
I really think most linux distros are too afraid of breaking UX
<pie_>
anyway im going to cut this short right now before i start ranting lmao
<pie_>
society at large seems to have moved towards accepting breakage more, for better or worse
<pie_>
at least thats a cliche with devops and whatnot
<pie_>
old timers might not be happy, but i mean, if we're making actual progress, thats good right?
<pie_>
inb4 someone runs into a 256 character command line limit on their 8 bit machine with the new tar and we break their workflow ;P
<pie_>
and im rambling.
<andi->
nixos doesn't run on 8bit hardware!!11 (me hopes both ways)
<pie_>
i guess the question is what is the least painful way to break workflows?
<andi->
break it early and loud.
<pie_>
btw how was the seaprate system / nix-shell bash thing handled in the end?
<pie_>
didnt that get homogenized at some point?
<pie_>
or am i remembering wrong
<pie_>
andi-, so, make remoting explicit, and make tar scream horribly if it can tell that its specifically a remoting error?
<pie_>
a la ivan 's suggestion to move to an explicit arg?
<andi->
maybe..
<andi->
not quiet sure yet
<pie_>
anyway i have very little actual experience so its not like what i say is well-founded.
* pie_
runs off to do other things o/
<ekleog>
<ivan> any thoughts on tar's rmt filename support? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290435 <-- stupid question: isn't that a security issue of nix without sandboxing? (the case of “nix verifies the hash, it's OK, then unpacks and it fetchs something else” -- I can't remember whether the file name is in the hash, but if not that could allow an untrusted user to preemptively forge
<ekleog>
corrupted system tools -- I'm assuming root wouldn't install a package with a : in the tar'd file name to say it's an issue iff the name isn't taken into account for the hash)
<andi->
well it's the same for any untrusted code that you execute without sandboxing :)
<ekleog>
hmm… but even w/o sandboxing the build is run as a nixbld* builder, right? which aren't supposed to be used twice at the same time
<ekleog>
I mean, here it'd allow me to just build a patched `sudo` and recover the root password, by asking nix to just build the derivation for sudo only changing the filename (but keeping the file hash, so if nix doesn't include the filename in the nix hash then it won't notice)
<ekleog>
I can add files fetched without any url with the right nix-store incantation
<ekleog>
so something in my interpretation is wrong
<ekleog>
oh yeah, because that's a fixed-output derivation
<ekleog>
*but* in a .drv I can find `("src", "/nix/store/pf2nrsjnxyd4n8pyz8zp7lkj3swgpyap-unbound-1.6.8.tar.gz")`, so the file name should be taken into account for the hash of the tar call indeed :)
<ekleog>
so long as it's not directly un-tarr'd by the builder of the FO derivation… but in this case it must have a FO result so it's not a problem anyway