end-to-end encoding self-test

zooko commented

2008-05-05 21:07:07 +00:00

Owner

Figure out what is going on with Ben Laurie's Tahoe node on his FreeBSD-6 using the public Test Grid, make it reproducible if possible in the unit tests, fix it.

tahoe-lafs added the

labels 2008-05-05 21:07:07 +00:00

tahoe-lafs added this to the undecided milestone 2008-05-05 21:07:07 +00:00

zooko commented

2008-05-05 21:08:36 +00:00

Author

Owner

Milestone 1.0.1 deleted

tahoe-lafs added this to the 1.1.0 milestone 2008-05-05 21:08:36 +00:00

zooko commented

2008-05-05 23:02:26 +00:00

Author

Owner

See tahoe-dev:

http://allmydata.org/pipermail/tahoe-dev/2008-May/000542.html

See tahoe-dev: <http://allmydata.org/pipermail/tahoe-dev/2008-May/000542.html>

warner commented

2008-05-06 17:28:16 +00:00

Author

Owner

I'll read over the thread more closely and see if I can reproduce the problem locally.

I had first thought that it might just be the cap being corrupted, but that doesn't seem likely, given that the storage index is derived from the read-key.

I'll read over the thread more closely and see if I can reproduce the problem locally. I had first thought that it might just be the cap being corrupted, but that doesn't seem likely, given that the storage index is derived from the read-key.

warner commented

2008-05-06 20:05:24 +00:00

Author

Owner

ah, ok, pycryptopp vs the stack. nevermind.

zooko commented

2008-05-09 19:14:23 +00:00

Author

Owner

I'm working on adding "end to end" decryption, decoding, and parsing checks, i.e. in source:src/allmydata/test/test_encode.py upload some known-good, fixed ciphertext instead of encrypting, and likewise for SSK's and dirnodes.

tahoe-lafs changed title from ~~data corruption (integrity failure) bug on Ben Laurie's machine~~ to end-to-end encoding self-test

2008-05-12 19:47:08 +00:00

zooko commented

2009-03-28 19:38:40 +00:00

Author

Owner

The next step is to see what tahoe on Zandr's lenny-armel box does. The pycryptopp on that box seems to be giving incorrect decryption. Do the unit tests of tahoe on that box detect this misbehavior from pycryptopp?

zooko commented

2009-04-01 14:20:04 +00:00

Author

Owner

Assigning this to Zandr in case he wants to look at it before the next time I circle around and log into his Linksys NAS box...

The hope is that when tahoe is used with a broken pycryptopp that gives wrong answers, that the tahoe unit tests fail.

Assigning this to Zandr in case he wants to look at it before the next time I circle around and log into his Linksys NAS box... The hope is that when tahoe is used with a broken pycryptopp that gives wrong answers, that the tahoe unit tests fail.

zooko commented

2009-04-07 15:59:12 +00:00

Author

Owner

Some tests on Zandr's lenny-armel box do indeed fail, such as allmydata.test.test_system.SystemTest.test_upload_and_download_random_key. See the buildbot results: http://allmydata.org/buildbot/builders/Zandr%20Lenny-armel/builds/37/steps/test/logs/stdio . However, these are failing because encrypting a string and then decrypting the ciphertext doesn't yield the original string. A subtler bug (and one that we've had before in pycryptopp) is when encrypting the string and decrypting the ciphertext does yield the original string, but only when you use the same (buggy) code for both encryption and decryption. This ticket is to add a "test vector", for example a fixed ciphertext, computed with a known-good implementation of AES and then hardcoded into the test file as a string literal, and assert that when you decrypt that fixed ciphertext you get the correct plaintext.

Some tests on Zandr's lenny-armel box do indeed fail, such as `allmydata.test.test_system.SystemTest.test_upload_and_download_random_key`. See the buildbot results: <http://allmydata.org/buildbot/builders/Zandr%20Lenny-armel/builds/37/steps/test/logs/stdio> . However, these are failing because encrypting a string and then decrypting the ciphertext doesn't yield the original string. A subtler bug (and one that we've had before in pycryptopp) is when encrypting the string and decrypting the ciphertext does yield the original string, but only when you use the same (buggy) code for both encryption and decryption. This ticket is to add a "test vector", for example a fixed ciphertext, computed with a known-good implementation of AES and then hardcoded into the test file as a string literal, and assert that when you decrypt that fixed ciphertext you get the correct plaintext.

tahoe-lafs added this to the 1.4.1 milestone 2009-04-07 15:59:12 +00:00

zooko commented

2009-12-13 05:17:09 +00:00

Author

Owner

I'm making some progress on this, but it doesn't need to be done before Tahoe-LAFS v1.6.

tahoe-lafs modified the milestone from 1.6.0 to eventually

2009-12-13 05:17:09 +00:00

davidsarah commented

2010-02-02 00:29:33 +00:00

Author

Owner

Our tests are in general quite comprehensive, but this is a glaring omission.

tahoe-lafs modified the milestone from eventually to 1.7.0

2010-02-02 00:29:33 +00:00

tahoe-lafs added

critical

and removed

major

labels 2010-03-17 00:48:09 +00:00

zooko commented

2010-04-29 16:13:43 +00:00

Author

Owner

I think we might have some tests to detect this now. Here's how to find out: mock out the AES class from pycryptopp (which is used in the [immutable upload]source:src/allmydata/immutable/upload.py@4164#L441, [mutable publish]source:src/allmydata/mutable/publish.py@4164#L400, [immutable download]source:src/allmydata/immutable/download.py@4248#L45, and [mutable retrieve]source:src/allmydata/mutable/retrieve.py@4126#L518).

zooko commented

2010-04-29 16:15:23 +00:00

Author

Owner

…and then set the mock to encrypt-decrypt wrongly but consistently and then see if any tests fail.
Oh, and I guess this is also half of the job of writing the tests that we need! (If they aren't already there.) Shouldn't be too hard...

…and then set the mock to encrypt-decrypt wrongly but consistently and then see if any tests fail. Oh, and I guess this is also half of the job of writing the tests that we need! (If they aren't already there.) Shouldn't be too hard...

tahoe-lafs modified the milestone from 1.7.0 to eventually

2010-05-16 23:39:51 +00:00

zooko commented

2012-03-29 16:01:59 +00:00

Author

Owner

I'm demoting this from critical to major, since there are other urgent known-bugs (mostly in mutables) that are marked critical and this ticket, while certainly important, hasn't been touched in years.

I'm demoting this from `critical` to `major`, since there are other urgent known-bugs (mostly in mutables) that are marked `critical` and this ticket, while certainly important, hasn't been touched in years.

tahoe-lafs added

major

and removed

critical

labels 2012-03-29 16:01:59 +00:00

end-to-end encoding self-test #406