On 2013-May-31 12:01:02 +0200, Dirk-Willem van Gulik
wrote:
> Thanks to a badly-written mngt script -
>we've rencently noticed a freshly generated ssh-key on a new AWS
>instances to be indentical to one seen a few months prior.
...
>I am surmising that perhaps the (micro-T) images do not have tha
On 31 May 2013 20:50, "Dan Nelson" wrote:
>
> In the last episode (May 31), Reid Linnemann said:
> > On Fri, May 31, 2013 at 1:12 PM, Teske, Devin wrote:
> > > If you're arguing we have to change sh's behavior to be more
compliant,
> > > jilles already quoted XCU 2.12 (our shell is well within its
In the last episode (May 31), Reid Linnemann said:
> On Fri, May 31, 2013 at 1:12 PM, Teske, Devin
> wrote:
> > If you're arguing we have to change sh's behavior to be more compliant,
> > jilles already quoted XCU 2.12 (our shell is well within its right to
> > run any/all lvalue/rvalue operands o
On Fri, May 31, 2013 at 1:12 PM, Teske, Devin wrote:
>
> If you're arguing we have to change sh's behavior to be more compliant,
> jilles already quoted XCU 2.12 (our shell is well within its right to run
> any/all lvalue/rvalue operands of a pipe in a sub-shell without
> contradicting the guideli
On May 31, 2013, at 10:59 AM,
wrote:
> Redirections > and >> don't put it in a subshell.
Correct. (note: I made no such insinuation; But thanks for clarifying for
others that perhaps were not aware).
> Only pipe |, which means only STDIN affects/triggers this behaviour.
> Does < operator al
Redirections > and >> don't put it in a subshell.
Only pipe |, which means only STDIN affects/triggers this behaviour.
Does < operator also does it, as it is also STDIN?
Anyway, I don't care for executing binaries, but I do care if that is part of
sh's code, as function is.
It messes var scopes.
On 05/25/13 06:44, Welcome, Traiano wrote:
a) What kind of hardware (processor) would I use as a development
platform, given the requirements of cheap, well documented, easily
obtainable, easy to debug etc ... I believe the hardware platform chosen
should satisfy the following requirements
Hi all,
I think I've discovered a strange behaviour of sed perhaps triggered
by the length of a regex passed to it. I noticed that a certain
expression I passed took a very long time, and suspected the usual
backtracking loop, so I started trimming it... and discovered this:
[crees@pegasus]~% ti
.. snipped...
# Seed Software random generator
#
cat rnd > /dev/random
# Activate software random generator as an additional source
sysctl kern.random.sys.harvest.swi=1
Or does this cause a loss/reset of all entropy gathered by the hardware sofar
On Fri, 31 May 2013 14:26:39 +0200
Dirk-Willem van Gulik wrote:
>
> Op 31 mei 2013, om 14:02 heeft RW het
> >># Activate software random generator as an additional
> >> source sysctl kern.random.sys.harvest.swi=1
> >
> > IIRC this doesn't do anything
>
> Thanks. So the man page says:
>
Op 31 mei 2013, om 14:02 heeft RW het volgende
geschreven:
> On Fri, 31 May 2013 12:01:02 +0200 Dirk-Willem van Gulik wrote:
>> # Seed Software random generator
>> #
>> cat rnd > /dev/random
>
> To be on the safe side you should sleep for about 0.5 seconds after
> this
>
>>
>
On Fri, 31 May 2013 12:01:02 +0200
Dirk-Willem van Gulik wrote:
> Now we happen to have very easy access to blocks of 1024bits of
> randomness from a remote server in already nicely PKI signed packages
> (as it is needed later for something else).
>
> Is it safe to simply *add* those with:
>
>
Thanks to a badly-written mngt script - we've rencently noticed a freshly
generated ssh-key on a new AWS instances to be indentical to one seen a few
months prior.
Careful analysis of some other logs showed that we've had similar clashes on
another script just after startup generating a very s
13 matches
Mail list logo
