CAcert Code Development list.

[Benny Baumann <benbe AT cacert.org>]

Hi,

Am 04.02.2015 um 11:43 schrieb Ian G:
> On 3/02/2015 22:30 pm, Benny Baumann wrote:
>> Thus: What you do while WIP is your business, but the versions effective
>> to our members should require established version control.
> 
> 
> On the other hand... it does occur that there is one other risk. The
> crit system has to display the content of the policy to the users in the
> event of a new registration, or otherwise make it available.  It has to
> get the "right" one and it has to make sure that it has no nasty stuff
> injected into it.  In effect the high-sec site is displaying content
> from a medium-sec site, and therefore disturbing the security perimeter.
> 
As I want to avoid this I strongly discourage the reverse proxy, as
previously stated. Instead the system should place links to the policy
documents (just as it is doing already).

Also, as noted, most risks can be mitigated to some extend by
restricting what a specific host my provide content-wise (using CSP I
mentioned). Given such a filter, even if an attacker injected JS into
policy documents, a user using a modern browser like Firefox or Chrome
won't be affected as the browsers would simply ignore the JS.

> We (policy group and members and arbitration) will pick up the first
> risk.  However the second risk probably means that crit system has to
> scrub the file every time it brings it in.  Or cache it.  Or scrub &
> hash it.  Or...
> 
> Hmm, maybe this is overthinking it, maybe crit-system can simply display
> a link.
I'm for the simple link here. Attacking the server serving the policy
documents is of much less interest to an attacker: Yes, it causes pain,
but it's much more painful if an attacker could get into the
(same-origin) domain of the crit system.
> 
> Maybe Policy is not the right group for this, CC to devel.
Thx, I hope this explains some assumptions.
> 
> iang
> 
BenBE.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature