To think that they would be ignored if they are as important as
everyone is making them out to be seems a shame.
It's called organization. Putting a central resource where you can
subscribe to - and yes, I did say you can actually subscribe to the
list - won't stop people from reading them.
Anyw
I'd rather they be seen.
On 3/29/07, Jarkko Laine <[EMAIL PROTECTED]> wrote:
> On 29.3.2007, at 19.34, Julian Tarkhanov wrote:
> > On Mar 29, 2007, at 5:25 PM, Tom Ward wrote:
> >> +1. I'd like the notices to remain in rails-core
> >>
> >> Tom
> >
> > In fact I've reconcidered and I also give a
On 29.3.2007, at 19.34, Julian Tarkhanov wrote:
On Mar 29, 2007, at 5:25 PM, Tom Ward wrote:
+1. I'd like the notices to remain in rails-core
Tom
In fact I've reconcidered and I also give a +1 now
CI is awareness and IMO the fact that errors clog the main list
prompts to fix them faster
+1
On Mar 29, 2007, at 9:56 PM, S. Robert James wrote:
On Mar 29, 9:49 pm, Brad Ediger <[EMAIL PROTECTED]> wrote:
Agreed that "some secret phrase" will not yield 256 or even 128 bits
of entropy. But the Rails app generator uses a version of
generate_unique_id, which uses just about all of the syst
On Mar 29, 9:49 pm, Brad Ediger <[EMAIL PROTECTED]> wrote:
> > 2. Entropy
> > Related to #1: to resist brute force attacks, you really want 128
> > bits, and preferably 256 bits, of entropy. The source code suggests
> > "some secret phrase", which is unlikely to come even close. The way
> > to
Great work, and an excellent analysis. Comments interspersed.
On Mar 29, 2007, at 8:23 PM, S. Robert James wrote:
Anyway, here's what we came up with:
1. Brute Force
SHA512 can be computed _very_ fast. On my Pentium Core Duo:
irb> z = 'z' * 100; puts Benchmark.measure { 1000.times
{ Digest::S
Aside from the replay attacks discussed, there are some other attack
vectors on the cookie_session store.
I appreciate (and admire!) Jeremy's good humor on all of this:
> Planting the seed here led to quick ripening and plenty of pesticide.
> Thanks for the fish, all.
>
> jeremy
Anyway, here's w
On Mar 29, 2007, at 2:43 PM, Thijs van der Vossen wrote:
On Mar 29, 2007, at 21:35, Jeremy Kemper wrote:
On 3/29/07, Obie Fernandez <[EMAIL PROTECTED]> wrote:
On 3/29/07, Tomas Jogin <[EMAIL PROTECTED]> wrote:
How about just NOT changing the default setting to this less secure
option? Problem
After a brief conversation yesterday, of which this was only a small
note, David suggest I mail the core list in regards to this.
We're having a bizarre issue where SQL is being logged to production,
regardless of even explicitly setting it to info in the configs. Of
course this is generating aro
On Mar 29, 2007, at 21:35, Jeremy Kemper wrote:
> On 3/29/07, Obie Fernandez <[EMAIL PROTECTED]> wrote:
>> On 3/29/07, Tomas Jogin <[EMAIL PROTECTED]> wrote:
>>> How about just NOT changing the default setting to this less secure
>>> option? Problem solved.
>>
>> + 1 It sounds like the decision t
On 3/29/07, Obie Fernandez <[EMAIL PROTECTED]> wrote:
> On 3/29/07, Tomas Jogin <[EMAIL PROTECTED]> wrote:
> > How about just NOT changing the default setting to this less secure
> > option? Problem solved.
>
> + 1 It sounds like the decision to make cookie store the default was
> premature, at b
> I think it's time to say that the continuous integration, break/fixed
> notices should be moved to a new list.
Moving them to another list will simply create an error message ghetto
which no one checks. I'm happy with them here at present, and their
volume is tiny relative to the discussion th
I'm trying to hack ActiveResource to use a self-signed certificate when
connecting to my RESTful rails app (seems like a pretty glaring hole
that it doesn't offer this out of the box... though I guess it is alpha
software).
I started out going through the ActiveResource code looking for
somewher
On Mar 29, 2007, at 5:25 PM, Tom Ward wrote:
>
> +1. I'd like the notices to remain in rails-core
>
> Tom
In fact I've reconcidered and I also give a +1 now
CI is awareness and IMO the fact that errors clog the main list
prompts to fix them faster
--
Julian 'Julik' Tarkhanov
please send all
On 29/03/07, Alexey Verkhovsky <[EMAIL PROTECTED]> wrote:
> On 3/29/07, Nathaniel Brown <[EMAIL PROTECTED]> wrote:
> > > > I think it's time to say that the continuous integration, break/fixed
> > > > notices should be moved to a new list.
> >
>
> Just one question: what name that new list should
On 3/29/07, Nathaniel Brown <[EMAIL PROTECTED]> wrote:
>
> > > I think it's time to say that the continuous integration, break/fixed
> > > notices should be moved to a new list.
>
Just one question: what name that new list should have? Should it be called
rails-core-core or rails-notices-that-nobo
On Mar 29, 2007, at 2:02 AM, Thijs van der Vossen wrote:
On Mar 29, 2007, at 3:48, Brad Ediger wrote:
On Mar 27, 2007, at 9:46 PM, S. Robert James wrote:
As I said earlier, I'm waiting for a spec and sample app before
working on a full review.
I went ahead and wrote up a spec. Here's my fir
On 3/29/07, Tomas Jogin <[EMAIL PROTECTED]> wrote:
>
> How about just NOT changing the default setting to this less secure
> option? Problem solved.
+ 1 It sounds like the decision to make cookie store the default was
premature, at best.
By the way, just because this 'feature' is in EdgeRails d
No doubt then, seems you are already making procedures to silence it.
I could defiately create the filter as well, but I am sure I am not
the only one noticing that the emails on core would have more impact
if we didn't have to sift through the commit checks. Especially as
more systems are setup i
Have any metrics been gathered on the "performance/scalability" of the new
method or is it imaginary premature optimization?
On 3/29/07, Isak Hansen <[EMAIL PROTECTED]> wrote:
>
>
> On 3/21/07, S. Robert James <[EMAIL PROTECTED]> wrote:
> >
> > I'm concerned about the possibility of replay attacks
Hi,
The applied patch changes two tests in activerecord/test/base_test.rb to
not be dependent on hash ordering. The patch is against stable.
Cheers
--
Ola Bini (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki
What's the rationale for not setting the foreign instance when using
<< but setting it when using .create, .build, etc.
Is it an oversight and should I raise a request or is it deliberate?
Cheers,
Simon
--~--~-~--~~~---~--~~
You received this message because yo
On Mar 29, 2007, at 10:22, Sam Bravard wrote:
> Short summary: someone made a well meaning change to sessions that is
> broken and creates more pain than it solves.
> Desired result: rollback the patch.
>
> DHH, what say you?
The 'someone' was [1] bitsweat aka Jeremy Kemper who works for
37sign
On 3/29/07, Nathaniel Brown <[EMAIL PROTECTED]> wrote:
>
>
> I think it's time to say that the continuous integration, break/fixed
> notices should be moved to a new list.
I had this filter in GMail for a long time now:
Matches: *to:rubyonrails subject:("AR/Oracle Unit Test" OR SQLServer OR
"
I think it's time to say that the continuous integration, break/fixed
notices should be moved to a new list.
It's seriously diluting the important conversations real humans are
having. As much as I thoroughly enjoy seeing the reports and status
updates. It means little to nothing to me on a "live
How about just NOT changing the default setting to this less secure
option? Problem solved.
On 3/29/07, Isak Hansen <[EMAIL PROTECTED]> wrote:
>
> On 3/21/07, S. Robert James <[EMAIL PROTECTED]> wrote:
> >
> > I'm concerned about the possibility of replay attacks with cookie
> > sessions. This i
On 3/21/07, S. Robert James <[EMAIL PROTECTED]> wrote:
>
> I'm concerned about the possibility of replay attacks with cookie
> sessions. This is a standard security issue.
>
Just adding my $0.02:
I like the shared-nothing cookie store as an option, for
performance/scalability reasons. Just docu
Someone on Caboose want to chime in and bring this thread to rest?
Short summary: someone made a well meaning change to sessions that is
broken and creates more pain than it solves.
Desired result: rollback the patch.
DHH, what say you?
On Mar 29, 12:02 am, Thijs van der Vossen <[EMAIL PROTECTE
28 matches
Mail list logo
