I'm running Bash 4.3.30(1)-release on Arch Linux. Recently after I rebooted by
system I realized that all my Bash History had been erased. The ~/.bash_history
file existed, but it was completely empty.
The situation occurred just now once again. I boot up my system and realize that
I have no b
Hi all,
the errexit option can be very useful in simple scripts. This option
is being ignored in many contexts like lists and conditionals though.
I understand that this is "by design" and that errexit cannot be
"fixed" to behave more reasonably. Still, this makes bash a lot less
useful than it co
On 2 Sep 2014 16:48, "Chet Ramey" wrote:
>
> On 9/2/14, 5:37 AM, Notes Jonny wrote:
>
> > Hi Guys
> >
> > Any update on implementing this?
>
> I haven't done anything with this yet. If and when it happens, it will
> show up in the devel git branch on savannah.
>
> Chet
>
> --
> ``The lyf so short
Andreas Grünbacher wrote:
> Hi all,
>
> the errexit option can be very useful in simple scripts. This option
> is being ignored in many contexts like lists and conditionals though.
> I understand that this is "by design" and that errexit cannot be
> "fixed" to behave more reasonably. Still, this m
Hello Chet,
Re: testing for Shellshock... would like your feedback... specifically,
regarding the possibility of human-directed combinatorial testing to find this
Bash vulnerability...
Given the knowledge about Shellshock that's been developed, I'm wanting to
define more of the attack surface
Wow, that's a very long email.
While it's possible to fuzzy test bash, the problem is, first, you
have to find a way to generate strings that maximize the chance of
being a genuine command or a command that triggers a bug. This is
very expensive...
Second, once you generate a command, how will yo
Darshit Shah wrote:
> I'm running Bash 4.3.30(1)-release on Arch Linux. Recently after I rebooted
> by system I realized that all my Bash History had been erased. The
> ~/.bash_history file existed, but it was completely empty.
>
> The situation occurred just now once again. I boot up my system an
On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote:
> Hello Chet,
>
> Re: testing for Shellshock... would like your feedback... specifically,
> regarding the possibility of human-directed combinatorial testing to find
> this Bash vulnerability...
Sounds like how Michal Zalewski found the re
Greg Wooledge wrote:
there is a
file named /etc/udev/rules.d/70-persistent-net.rules
Perhaps you should get in touch with a SuSE mailing list and see how
other SuSE users have dealt with this. You might be reinventing the
wheel.
---
SuSE has had the same file. At first we were told port n
On 10/8/14, 8:17 PM, jon wrote:
> dmesg.
>
> [307688.764489] configure[25847]: segfault at 9558104 ip 080e2246 sp bfd478f0
> error 4 in bash[8048000+148000]
> [307689.436739] configure[25966]: segfault at 95580b4 ip 080e2246 sp bfd478f0
> error 4 in bash[8048000+148000]
> [307689.467279] con
On 10/9/14, 3:05 PM, Notes Jonny wrote:
>> If and when it happens, it will
>> show up in the devel git branch on savannah.
>>
>> Chet
> Thank you for your reply.
>
> I understand that requests can't be implemented immediately.
>
> Is there anything I could do to get this implemented? Eg. I woul
On Thu, 2014-10-09 at 19:56 -0400, Chet Ramey wrote:
> On 10/8/14, 8:17 PM, jon wrote:
> > dmesg.
> >
> > [307688.764489] configure[25847]: segfault at 9558104 ip 080e2246 sp
> > bfd478f0 error 4 in bash[8048000+148000]
> > [307689.436739] configure[25966]: segfault at 95580b4 ip 080e2246 sp
On 10/9/14, 9:06 PM, jon wrote:
> On Thu, 2014-10-09 at 19:56 -0400, Chet Ramey wrote:
>> On 10/8/14, 8:17 PM, jon wrote:
>>> dmesg.
>>>
>>> [307688.764489] configure[25847]: segfault at 9558104 ip 080e2246 sp
>>> bfd478f0 error 4 in bash[8048000+148000]
>>> [307689.436739] configure[25966]: s
On 10/9/14, 8:20 AM, Andreas Grünbacher wrote:
> Hi all,
>
> the errexit option can be very useful in simple scripts. This option
> is being ignored in many contexts like lists and conditionals though.
> I understand that this is "by design" and that errexit cannot be
> "fixed" to behave more reas
On 10/9/14, 6:06 PM, Pádraig Brady wrote:
> On 10/09/2014 08:46 PM, Rick Karcich (rkarcich) wrote:
>> Hello Chet,
>>
>> Re: testing for Shellshock... would like your feedback... specifically,
>> regarding the possibility of human-directed combinatorial testing to find
>> this Bash vulnerability.
On 10/9/14, 4:50 PM, Eduardo A. Bustamante López wrote:
> Second, once you generate a command, how will your test program know
> if it found a bug? It's easy when bash segfaults, but in the case of
> shellshock, it wasn't a crash.
This is the problem. It's hard to tell whether bash reporting a s
On 10/9/14, 3:46 PM, Rick Karcich (rkarcich) wrote:
> Hello Chet,
>
> Re: testing for Shellshock... would like your feedback... specifically,
> regarding the possibility of human-directed combinatorial testing to find
> this Bash vulnerability...
>
> Given the knowledge about Shellshock that's
If I compile from bash-4.2 from source, cumulatively applying patches through
52, things work fine. If I start from scratch and apply through 53, it errors
out:
gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde
-L./lib/malloc -L./lib/sh -rdynamic -g -O2 -o bash she
On Oct 9, 2014, at 9:34 PM, TODD TRIMMER wrote:
> If I compile from bash-4.2 from source, cumulatively applying patches through
> 52, things work fine. If I start from scratch and apply through 53, it errors
> out:
>
> gcc -L.. . .
> ./builtins/libbuiltins.a(evalstring.o): In function `parse_
I would still propose that a simple and powerful way to extend Bash with
exception handling would be to extend the ERR trap by passing it some metadata
about the type and location of the exception incurred so that it can be handled
by user code. This proposal allows us to largely avoid having to an
20 matches
Mail list logo
