headers
Gervase Markham | 11 Jan 2012 18:36
Picon
Favicon
Gravatar

Re: Policy discussion list that is read-only for the public

Hi Ben,

On 11/01/12 17:07, Ben Bucksch wrote:
> The majority of discussions here on this list are policy discussions
> that are not specifically about bugs that are still embargoed, but
> either general "what should we do about this whole class of problems" or
> about security bugs that are already in the wild and we need to react to
> that. So, there is no inherent need to keep these discussions hidden.
> 
> For those discussions which do need to stay hidden from public view, we
> can keep this list. For all others, we could theoretically use
> mozilla.dev.security, but there's way too much noise there, so nobody of
> importance reads it. I tried posting there several times, and got
> practically no  relevant responses. 

There hasn't been a post in mozilla.dev.security since October; what do
you mean by "way too much noise"?

If our security community is not, on the whole, members of our public
security discussion forum, then that's a problem - but setting up
another forum is not necessarily the solution to it.

Perhaps people on s-g who are not members of m.d.s can say why they
aren't? Didn't know about it? Was once a member but it seemed off-topic?
Something else?

> The point would be that there is a public track record of our decisions
> and why we made them, but we avoid the noise.

I don't think discussions happen here solely for lack of a suitable
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ben Bucksch | 11 Jan 2012 18:07

Policy discussion list that is read-only for the public

Hey all,

dveditz <#dveditz> just said on IRC: "this is better as a mail 
conversation I think -- either mozilla.dev.security or security-group 
(depending on your taste for open-but-small-audience vs 
better-audience-but-hidden)"

This perfectly phrases and frames the problem. We're an open-source 
project and for me that also means openness in project structure, 
decision-making and leadership. Transparency.

The majority of discussions here on this list are policy discussions 
that are not specifically about bugs that are still embargoed, but 
either general "what should we do about this whole class of problems" or 
about security bugs that are already in the wild and we need to react to 
that. So, there is no inherent need to keep these discussions hidden.

For those discussions which do need to stay hidden from public view, we 
can keep this list. For all others, we could theoretically use 
mozilla.dev.security, but there's way too much noise there, so nobody of 
importance reads it. I tried posting there several times, and got 
practically no  relevant responses. I suggest:

Create a mailing-list that is moderated. Members of the security-group 
get automatically subscribed (but they can optionally unsubscribe 
themselves, if they really don't want it), and they can post without 
moderator approval. Everybody else can read it, and it has a newsgroup 
equivalent, but nobody can post from there.

The point would be that there is a public track record of our decisions
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kyle Hamilton | 12 Jan 2012 04:38
Picon

Re: Policy discussion list that is read-only for the public


On Wed, Jan 11, 2012 at 9:36 AM, Gervase Markham <gerv <at> mozilla.org> wrote:
> Mozilla needs a space in between "public" and "security group" (or
> "employees"). We've needed one for a long time; this is just another
> manifestation of the issue.

So how about representation of the users' interests within the "security group" or "employees" via an
elected or appointed position?

Right now, the security group (particularly the participants in the CABF from Mozilla) seems to be a place
where the end users, particularly the well-informed and strongly-motivated end users, have no voice at
all.  It seems to be a place where shadowy decisions are made in back-room deals by shady, non-elected characters.

Unfortunately, it also is the place where the end-users who want to do their own due diligence need to have
someone they can trust, but are stonewalled and stymied every time they try to effect any kind of change.

The "security group" and "employees" involved here are operating contrary to Mozilla's board-approved
principles.  Unless and until Mozilla shows that it has effective corporate governance and decision
auditing, it's getting no more of my donor dollars.  It's also getting my anti-Mozilla opinions slapped
everywhere.  (I live in Mountain View, 1.1 miles from the Castro Street headquarters.  Guess where much of
my oration is going to be?)  The security group's service to the Mozilla principles is a joke, it's a farce,
and Mozilla needs someone in that group who isn't going to just say "PKI me harder", who isn't so certain
that his or her vision of PKI is the only correct interpretation that he/she/they completely shut out any
and all attempts to change the PKI status quo with "RESOLVED INVAL
 ID", without any engagement in any kind of dialogue about why or how these attempts might actually have merit.

In other words, the employees need to have their ivory tower demolished.  Until that happens, no progress
toward actual user security can be made.

-Kyle H
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henri Sivonen | 12 Jan 2012 09:10
Picon
Picon
Favicon

Is Mozilla actively working to introduce CAless TLS public key checking?

After reading about CA compromises again and again, I am wondering:

Is Mozilla actively working on a TLS public key checking system that
has real trust agility (not DNSsec!) and that doesn't require CAs to
work (but that can work in parallel with the CA system)?

Building Convergence into Firefox perhaps? (I'm aware that Convergence
doesn't work in captive portals and that business incentives that'd
result in a diverse high-availability network of notaries are
unclear.)

--

-- 
Henri Sivonen
hsivonen <at> iki.fi
http://hsivonen.iki.fi/
Permalink | Reply | 0 comments |
headers
Daniel Veditz | 12 Jan 2012 17:10

Re: Policy discussion list that is read-only for the public

On 1/11/12 7:38 PM, Kyle Hamilton wrote:
> Right now, the security group (particularly the participants in
> the CABF from Mozilla)

There have been zero discussions about CABF stuff on the private
security-group mailing list. The only time I recall PKI-in-general
topics coming up is in the heat of dealing with recent CA compromises.

> seems to be a place where the end users, particularly the
> well-informed and strongly-motivated end users, have no voice at
> all.  It seems to be a place where shadowy decisions are made in
> back-room deals by shady, non-elected characters.

I think you're confusing this dev-security list with
dev-security-policy, which might have been better called
dev-tech-crypto-policy to emphasize it's relation with the crypto
group. This list covers pretty much everything BUT the crypto/PKI
policy.

> (I live in Mountain View, 1.1 miles from the Castro Street
> headquarters. Guess where much of my oration is going to be?)

We should have lunch then. Come on down! Mail in advance to
schedule, would be a bummer if you dropped in on a day I already had
something planned. If you're only interested in PKI-related security
issues we can make sure some of those folks are around, too. Some of
the Red Hat guys who work on NSS are just a couple blocks down from
Mozilla.

-Dan Veditz
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Veditz | 12 Jan 2012 17:10

Re: Policy discussion list that is read-only for the public

On 1/11/12 7:38 PM, Kyle Hamilton wrote:
> Right now, the security group (particularly the participants in
> the CABF from Mozilla)

There have been zero discussions about CABF stuff on the private
security-group mailing list. The only time I recall PKI-in-general
topics coming up is in the heat of dealing with recent CA compromises.

> seems to be a place where the end users, particularly the
> well-informed and strongly-motivated end users, have no voice at
> all.  It seems to be a place where shadowy decisions are made in
> back-room deals by shady, non-elected characters.

I think you're confusing this dev-security list with
dev-security-policy, which might have been better called
dev-tech-crypto-policy to emphasize it's relation with the crypto
group. This list covers pretty much everything BUT the crypto/PKI
policy.

> (I live in Mountain View, 1.1 miles from the Castro Street
> headquarters. Guess where much of my oration is going to be?)

We should have lunch then. Come on down! Mail in advance to
schedule, would be a bummer if you dropped in on a day I already had
something planned. If you're only interested in PKI-related security
issues we can make sure some of those folks are around, too. Some of
the Red Hat guys who work on NSS are just a couple blocks down from
Mozilla.

-Dan Veditz
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Veditz | 12 Jan 2012 20:24

Re: Is Mozilla actively working to introduce CAless TLS public key checking?

On 1/12/12 12:10 AM, Henri Sivonen wrote:
> Is Mozilla actively working on a TLS public key checking system that
> has real trust agility (not DNSsec!) and that doesn't require CAs to
> work (but that can work in parallel with the CA system)?

Not "actively", no. It's too early to determine if that's a fruitful
approach to build it into Firefox. We should, however, make some
changes so it's easier to develop experiments like Convergence.

-Dan Veditz
Permalink | Reply | 0 comments |
headers
Kevin Chadwick | 24 Jan 2012 23:53
Picon
Favicon

Please bring back JIT options in about:config for PAX/Grsecurity compatibility (Hardened Linux)

Currently the only web browser I've found that runs with grsecurity/pax
with all security features such as "PAX" Mprotect and RANDMMAP is Opera.

"http://pax.grsecurity.net/docs/mprotect.txt"
"http://en.wikibooks.org/wiki/Grsecurity/Appendix/PaX_Flags"

I care more about security than javascript speed but I don't wish to
spend the time or energy fixing and compiling firefox to work with a
secure linux kernel that avoids so many 0-day exploits.

I run firefox in a sandbox for the occasional time flash is required
and I am being pushed towards the closed source Opera for general use
by my businesses when I'd prefer to stick with firefox outside the
sandbox which I have been using since firebird.

A bug has been opened in the past but was mistaken for firefoxes
mprotect and incorrectly closed.

The problem is Just In Time execution which requires write and execute
at the same time which should be optional and not explicitly compiled
in. Users should atleast be able to allow RWX via paxctl, load up
firefox set methodjit and tracejit off in about:config and re-enable the
security (disable RWX).

It used to be possible

"http://hardenedgentoo.blogspot.com/2010/07/grsecurity-firefox-mprotect-and-you.html"

Then it got harder for firefox 4
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Melven | 25 Jan 2012 00:33

Re: Please bring back JIT options in about:config for PAX/Grsecurity compatibility (Hardened Linux)


Hi Kevin,

in a current FF 9 release I see the following prefs :

javascript.options.jitprofiling.chrome;true
javascript.options.jitprofiling.content;true
javascript.options.methodjit.chrome;true
javascript.options.methodjit.content;true
javascript.options.methodjit_always;false
javascript.options.tracejit.chrome;true
javascript.options.tracejit.content;true

does setting these options to false let Firefox run under PAX 
with RWX disabled ?

(also please note that there is no more tracejit in Firefox 10 and later)

thanks !
ian

----- Original Message -----
From: "Kevin Chadwick" <ma1l1ists <at> yahoo.co.uk>
To: dev-security <at> lists.mozilla.org
Sent: Tuesday, January 24, 2012 2:53:24 PM
Subject: Please bring back JIT options in about:config for PAX/Grsecurity	compatibility (Hardened Linux)

Currently the only web browser I've found that runs with grsecurity/pax
with all security features such as "PAX" Mprotect and RANDMMAP is Opera.
(Continue reading)

Permalink | Reply | 1 comment |
headers
weizhong qiang | 25 Jan 2012 10:06
Picon

How can I output the uncrypted private key as part of p12

Hi all,
I find the method PK11_ExportPrivateKeyInfo is empty. Could you tell me how can I output the private key
(without encryption) as part of pkcs 12 file?

Best Regards,
Weizhong Qiang
Permalink | Reply | 0 comments |

Gmane