Merge lp:~benji/launchpad/bug-580035 into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Māris Fogels on 2010-08-17 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 11392 |
| Proposed branch: | lp:~benji/launchpad/bug-580035 |
| Merge into: | lp:launchpad |
| Diff against target: |
933 lines (+308/-105) 7 files modified
lib/canonical/launchpad/mail/errortemplates/old-signature.txt (+2/-0) lib/canonical/launchpad/mail/handlers.py (+9/-4) lib/canonical/launchpad/mail/helpers.py (+20/-1) lib/canonical/launchpad/mail/tests/test_handlers.py (+87/-1) lib/canonical/launchpad/mail/tests/test_helpers.py (+46/-1) lib/canonical/launchpad/utilities/gpghandler.py (+21/-32) lib/lp/bugs/tests/bugs-emailinterface.txt (+123/-66) |
| To merge this branch: | bzr merge lp:~benji/launchpad/bug-580035 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Deryck Hodge (community) | code | Approve on 2010-08-18 | |
| Māris Fogels (community) | 2010-08-17 | Approve on 2010-08-17 | |
|
Review via email:
|
|||
Description of the Change
Commands can be sent to bugs via GPG signed email. The commands don't contain
a nonce, so if someone were able to get ahold of an email from someone they
could resend it later (bug 580035).
This branch greatly reduces the effective window for such an attack by
rejecting any email message containing commands if the signature was generated
too long ago (more than 48 hours).
To help avoid attacks that arise from people accidentally having their clocks
set too far in the future and thus creating messages that can be reused for a
long time, the branch also rejects emails with commands that were signed more
than 10 minutes in the future.
This approach is suggested fix number 3 in the bug description.
I had a pre-implementation discussion with Gary and he had one with Francis.
The bug email tests had a natural place to add tests for this behavior. To run
the tests:
bin/test -ct bugs-emailinter
I fixed a large amount of lint (but I don't think it pollutes the diff too
much). Here's the lint report that I made go away:
Linting changed files:
lib/canonical
lib/canonical
lib/canonical
lib/canonical
lib/lp/
./lib/canonical
353: W191 indentation contains tabs
353: E101 indentation contains mixed spaces and tabs
353: Line contains a tab character.
./lib/canonical
78: E202 whitespace before ']'
138: E302 expected 2 blank lines, found 1
./lib/canonical
78: E211 whitespace before '('
288: E202 whitespace before ')'
470: E202 whitespace before '}'
./lib/lp/
79: source exceeds 78 characters.
341: source exceeds 78 characters.
575: narrative exceeds 78 characters.
967: source exceeds 78 characters.
1226: source exceeds 78 characters.
1230: source has bad indentation.
1447: want exceeds 78 characters.
1473: narrative exceeds 78 characters.
1489: want exceeds 78 characters.
1502: want exceeds 78 characters.
1894: source exceeds 78 characters.
1895: source exceeds 78 characters.
2344: narrative has trailing whitespace.
2583: narrative has trailing whitespace.
2584: narrative has trailing whitespace.
2585: narrative has trailing whitespace.
2696: source exceeds 78 characters.
2895: want exceeds 78 characters.
| Deryck Hodge (deryck) wrote : | # |
Benji and I chatted on IRC. I would indeed prefer this be converted to a unit test. I would prefer it before it lands (best laid plans and all that... ;)), but I won't block on that point. Thanks for pointing that out, Maris!
Cheers,
deryck
| Deryck Hodge (deryck) wrote : | # |
The updates to make this a unit test look good to me, Benji. Thanks!

Hi Benji,
Once again, these changes look good. I really like the use of named variables for time durations in ensure_ sane_signature_ timestamp( ). It really improves the readability.
One question I did have: did you have a pre-implementation call with the bugs team about this? IIRC at the last EPIC gmb was in the process of killing all doctests in bugs. I would think the bugs team members would have asked for unit tests of this new feature.
If it turns out that the bugs team does in fact want unit tests, then I am sure you can land this as-is and land a follow-up branch soon after.
Looks good, r=mars.
Maris