On 2010/04/07 10:43 PDT, Matt McCutchen wrote:
> On Wed, 2010-04-07 at 09:55 -0700, johnjbarton wrote:
>> On 4/4/2010 10:41 PM, Daniel Veditz wrote:
>>> We plan on alerting users in a future update. This is fair warning
>>> to server operators and those who are debugging their sites.
>>
>> If th
In article <20100407160150.2b5d0637.r...@reedloden.com> you wrote:
> On Wed, 7 Apr 2010 16:18:41 -0400
> Ben Boeckel wrote:
>
>> While going through fixing memory leaks in CHASM[1], I fixed some leaks
>> within NSPR and NSS.
>
> Ben, thanks for the work here. Always great to have outside
> contr
On Wed, 7 Apr 2010 16:18:41 -0400
Ben Boeckel wrote:
> While going through fixing memory leaks in CHASM[1], I fixed some leaks
> within NSPR and NSS.
Ben, thanks for the work here. Always great to have outside
contributions for Mozilla projects. Open source is what makes this
project great.
If
Hi,
While going through fixing memory leaks in CHASM[1], I fixed some leaks
within NSPR and NSS. Here's a list of the leaks that CHASM exposed
(doing minimal things with NSS, basically just hashing):
* The error tables are not cleaned up. This is the most invasive
change since it adds a new
On Wed, 2010-04-07 at 09:55 -0700, johnjbarton wrote:
> On 4/4/2010 10:41 PM, Daniel Veditz wrote:
> > On 4/3/10 9:30 AM, johnjbarton wrote:
> >> If the *users* of Firefox are truly in jeopardy, then this alert should
> >> be provided to *users*. Since this alert is not shown to users I can
> >> on
On 4/4/2010 10:41 PM, Daniel Veditz wrote:
On 4/3/10 9:30 AM, johnjbarton wrote:
If the *users* of Firefox are truly in jeopardy, then this alert should
be provided to *users*. Since this alert is not shown to users I can
only assume that in fact there is no practical threat here. You're
putting
On Apr 7, 12:47 am, Kurt Seifried wrote:
> What about "www.paypal.com[NULL].yourcompany.com"? I assume that would
> be allowed by the name constraint with respect to fixed software, but
> still hit some older software that has the NULL certificate bug.
I think "www.paypal.com[NULL].yourcompany.co
On Apr 4, 6:48 am, Eddy Nigg wrote:
> It's trivial from the logical point of view.
That's easy for you to say. Even things that are logically trivial
are easy to miss unless one goes carefully over every single step of
the process. For instance, I used a little script to check
certificates agai
On Apr 3, 9:45 am, Jean-Marc Desperrier wrote:
> It's the sites that need to catch on those updates.
> And web developers can have power to influence those sites to update.
FWIW, I am a DreamHost customer and I just submitted a support ticket
with them to close the vulnerability for customer site
On 2010-04-07 01:54 PST, Jean-Marc Desperrier wrote:
> Matt McCutchen wrote:
>> On Apr 6, 5:54 am, Jean-Marc Desperrier wrote:
Matt McCutchen wrote:
> > An extended key usage of "TLS Web Server Authentication" on the
> > intermediate CA would constrain all sub-certificates, no?
>
On Apr 7, 4:54 am, Jean-Marc Desperrier wrote:
> Matt McCutchen wrote:
> > On Apr 6, 5:54 am, Jean-Marc Desperrier wrote:
> >> > Matt McCutchen wrote:
> >>> > > An extended key usage of "TLS Web Server Authentication" on the
> >>> > > intermediate CA would constrain all sub-certificates, no?
Matt McCutchen wrote:
On Apr 6, 5:54 am, Jean-Marc Desperrier wrote:
> Matt McCutchen wrote:
> > An extended key usage of "TLS Web Server Authentication" on the
> > intermediate CA would constrain all sub-certificates, no?
>
> You are here talking about a proprietary Microsoft extension
12 matches
Mail list logo
