On 3/11/2019 1:34 PM, Greg Wooledge wrote:
> It's not documented so much as blatantly obvious by looking at how it's
> implemented.
>
---
Undocumented features are subject to change at will. Those are called
'internals'. How they are implemented is not necessarily pertinent to
what documented features will be supported. I've never seen
a project guarantee their internal implementation of something that
has some sort of external spec or requirements.
>
> wooledg:~$ export -f title
> wooledg:~$ env | grep -A2 title
> BASH_FUNC_title%%=() { local IFS=' ';
> printf '\e]2;%s\a' "$*"
> }
>
>
> There's nowhere in that variable to store metadata such as original source
> file or line number. You'd need a second variable at the very least.
>
----
The 2nd variable is what I suggested:
To minimize impact, I'd probably store all of them in 1 place so I can
do text compression and encode in some storeable format -- at worse BASE64.
> It would require a modification of the function export/import code, and
> this would break compatibility *again* (just like the shellshock patches
> did when they changed the implementation).
>
----
Nope. If it is separate, and if it is only enabled upon an option. then
child instances would not change their behavior (in this case, by
displaying filename+line for funcs with -F) unless the debug block was
written out by BASH and the child bash was able to read it and process
the information. If the information is not there or corrupted/unreadable,
the child just ignores it as random stuff set in the environment (by
default).
How would that break compatibility? Compatibility was broken for show. The
real bug was bash reading past the end of the function foo(){;} BADCODE
-- at
least according to the recent writeup I read, but users can still
insert arbitrary functions into the environment and compatibility need
not have
been broken. For that matter a child bash could have been configurable with
some option to read the old format functions as well as the new or only
the new.
Compatibility breakage was purely optional, but such is the case
when outside people start running around yelling about "the sky", er,
"security
is falling!". Rational-thought exits as the project is held up in the light
for examination, scrutiny and often, ridicule.
Have seen that happen on more than one other project and the over-reaction
generally results in more long term damage than a simple fix of the problem.
In this case, the exploit would have required them to have physical
access to
my in-memory cache. Not impossible -- but improbable. If they do have
such access, a bash exploit is likely the least of my worries.
