On 07/08/2017 22:12, Alex Gaynor wrote:
You seem to be suggesting that the thoroughness of testing is somehow
related to how long it takes.
I'd expect any serious (or even not particularly serious...) to have a
comprehensive automated test suite that can verify that the software is
regression free and correct in minutes or hours. If you can't deploy
changes of any size with confidence in less than several months, I think
you have some serious process problems.
For non-essential changes, it may be a good idea to supplement the fast
automated tests by tests that take a lot longer. This could be manual
tests, or it could be tests that verify expiry procedures in real time
(e.g. issue a cert at the start of the test and verify that the OCSP
component acts as intended near the end of the test).
The need to deploy some changes quickly inevitably represents a
compromise between speed and quality, both in testing and coding. So
not using the rushed procedures for non-urgent changes is good general
practice.
Consider that most end-users are not encouraged to run Firefox nightlies
and that enterprise users tend to use special ESR releases with longer
release cycles than end users. These practices represent the same
fundamental speed/quality trade-off.
On Mon, Aug 7, 2017 at 4:09 PM, Jakob Bohm via dev-security-policy <
[email protected]> wrote:
On 07/08/2017 18:07, Hanno Böck wrote:
On Mon, 7 Aug 2017 15:59:07 +0000
Ben Wilson via dev-security-policy
<[email protected]> wrote:
FWIW - In the case of Telecom Italia, they have a commercial CA
product has a bug in it that occasionally causes this issue. They
may need some time for the software to be fixed/replaced.
I'm more worried by this statement than by the actual bug.
If you're a CA and are not able to fix a bug in your product in a timely
manner then you probably shouldn't be a CA.
If you are a CA or serious CA software vendor, you should not install
non-essential patches without a very long and thorough testing process.
Since this is (at most) a formal violation and not a security problem,
it is better for the fix to go through many month of careful testing
than to rush it through.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
