822535 - User-Oriented Labels in Data Manager for "sts/use" and "sts/subd"

Status: RESOLVED FIXED

(SeaMonkey :: Passwords & Permissions, defect)

Description

[David E. Ross]

SeaMonkey 2.14.1

When I open the Data Manager and view Permissions, I sometimes see "sts/use" and "sts/subd".  These labels are not user-oriented and should be replaced with labels that are.  

Note that implementation of bug #607124 in Core/Networking relative to these two permissions might require changes to the Data Manager.

Comment 1

[Philip Chee]

Attachment: WIP v0.1

Putting up this WIP for feedback.

Comment 2

[Robert Kaiser]

Comment on attachment 695196 [details] [diff] [review]
WIP v0.1

Well, those parts look OK but I'm very much inclined to not accept any more patches to dataman without tests. We are already missing some tests, IIRC, I don't want to let that grow.

Comment 3

[Philip Chee]

Attachment: Patch v1.1 with tests.

> Well, those parts look OK but I'm very much inclined to
> not accept any more patches to dataman without tests

I've added a test. I've no idea if this is the correct way of testing STS.

Comment 4

[Robert Kaiser]

Comment on attachment 702280 [details] [diff] [review]
Patch v1.1 with tests.

Have you actually run the test? I wonder slightly if the / in the .properties keys works fine - but the test should show that. ;-)

That said, please also check if sts/subd actually means "Use STS" by itself, or if it needs sts/use set at the same time and only means "Apply STS to subdomains (as well)". From the labels you have on there, it sounds right now that sts/subd would mean you don't need sts/use at the same time, as it would be redundant.

Comment 5

[Philip Chee]

> Have you actually run the test?
But of course!

> That said, please also check if sts/subd actually means "Use STS" by itself, or if it
> needs sts/use set at the same time and only means "Apply STS to subdomains (as well)".
> From the labels you have on there, it sounds right now that sts/subd would mean you
> don't need sts/use at the same time, as it would be redundant.

After looking at the source code:
http://mxr.mozilla.org/mozilla-central/source/security/manager/boot/src/nsStrictTransportSecurityService.cpp
and at the specs:
http://tools.ietf.org/html/draft-hodges-strict-transport-sec-02
It looks like the includeSubdomains is a flag in the STS header so yeah sts/subd means that sts/use is already included.

644     // AddPermission() will be called twice if the STS header encountered has
645     // includeSubdomains (first for the main permission and second for the
646     // subdomains permission). If AddPermission() gets called a second time
647     // with the STS_SUBDOMAIN_PERMISSION, we just have to flip that bit in
648     // the nsSTSHostEntry.

So sts/subd implies sts/use but is implemented as two separate permissions. Also removing the sts/use permission causes the sts/subd permission to be removed as well.

So do the strings need any changes?

Comment 6

[Robert Kaiser]

(In reply to Philip Chee from comment #5)
> > Have you actually run the test?
> But of course!

OK, then we have verified that this stuff in .properties works, that was always my fear with those.

> So sts/subd implies sts/use but is implemented as two separate permissions.
> Also removing the sts/use permission causes the sts/subd permission to be
> removed as well.
> 
> So do the strings need any changes?

Yes, I think it may be a good idea to label sts/subd as "Apply Strict Transport Security to subdomains".

Comment 7

[Philip Chee]

> Yes, I think it may be a good idea to label sts/subd as "Apply Strict Transport
> Security to subdomains".

Pushed to comm-central with string changed to "Apply Strict Transport Security to subdomains"
http://hg.mozilla.org/comm-central/rev/14e3af5ff3f8