<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>135866</bug_id>
          
          <creation_ts>2006-06-07 00:29 0000</creation_ts>
          <short_desc>app-crypt/truecrypt-4.2 is TESTED on AMD64</short_desc>
          <delta_ts>2006-08-22 06:19:25 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Ebuilds</component>
          <version>unspecified</version>
          <rep_platform>AMD64</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          <bug_file_loc>https://bugs.gentoo.org/show_bug.cgi?id=112197#c71</bug_file_loc>
          
          <keywords>TESTED</keywords>
          <priority>P3</priority>
          <bug_severity>enhancement</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>gtgentoo@tassone.net</reporter>
          <assigned_to>amd64@gentoo.org</assigned_to>
          <cc>ace@staticwave.ca</cc>
    
    <cc>b33fc0d3@gentoo.org</cc>
    
    <cc>crypto@gentoo.org</cc>
    
    <cc>david.helstroom@gmail.com</cc>

      

      
          <long_desc isprivate="0">
            <who>gtgentoo@tassone.net</who>
            <bug_when>2006-06-07 00:29:17 0000</bug_when>
            <thetext>In accordance with the following bug reference I am requesting that the ~amd64 keyword be added to the truecrypt ebuild:
https://bugs.gentoo.org/show_bug.cgi?id=112197#c71

I have done somewhat thorough testing of the new ebuild on amd64 with zero problems.  Please let me know if you&apos;d like any specific tests/results.

NOTE:  Daniel Black (Gentoo Dev Dragonheart) requested that this bug be assigned to crypto@gentoo.org.

Thanks much for your time!</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gtgentoo@tassone.net</who>
            <bug_when>2006-06-07 00:30:24 0000</bug_when>
            <thetext>Adding crypto@gentoo.org to the CC list.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dragonheart@gentoo.org</who>
            <bug_when>2006-06-07 03:30:31 0000</bug_when>
            <thetext>Greg if you can provide a rough test plan normally that is appreciated.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gtgentoo@tassone.net</who>
            <bug_when>2006-06-07 10:03:04 0000</bug_when>
            <thetext>No problem at all.  My testing including the following (roughly):

1) I Un-merged my existing test ebuilds of TrueCrypt and removed it from my custom overlay.  I then added the ~amd64 keyword to the real ebuild and emerged the new version.

2) I did some modprobing and removing of the truecrypt kernel module.  No problems found.

3) I performed a litany of tests with the truecrypt command-line client:

- I created a new encrypted volume (container) using various encryption settings.

- I created a ReiserFS filesystem inside of the encrypted volume.

- I did tests creating and writing to files inside of the encrypted volume.

- I mounted and unmounted the volume repeatedly.  I also ensured that the file contents were normal, non-corrupt, and accessible without errors across successive mounts of the volume.

All operations worked normally and without error (either at the CLI level or in the kernel ring-buffer).  Let me know if you&apos;d like anything more specific.  Thanks!</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dragonheart@gentoo.org</who>
            <bug_when>2006-06-07 17:45:34 0000</bug_when>
            <thetext>good summary. Needs a touch more detail. Arch testers generally are unfamiliar with the workings of truecrypt so specific commands (e.g. how to create truecrypt container?) and expected output will help them.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gtgentoo@tassone.net</who>
            <bug_when>2006-06-07 23:42:52 0000</bug_when>
            <thetext>Understood.  Following is a corresponding summary of commands performed.  Numbers indicate reference to my previously posted (rough) test plan in comment #3 :

2)
# modprobe truecrypt
# modprobe -r truecrypt
(Both followed by lsmod and dmesg for a ring-buffer check).

3. A)  Create encrypted volume (container):
# truecrypt --type normal --filesystem none --size 1000M --encryption AES --hash whirlpool -c test-vol.tc

B) Map new volume (to device 2 for testing) and ensure that it is online:
# truecrypt --device-number 2 test-vol.tc
# truecrypt -l

Create a ReiserFS filesystem within the mapped volume:
# mkreiserfs /dev/mapper/truecrypt2

C) Mount the new filesystem within the encrypted volume and ensure it is mounted:
# mount -t reiserfs /dev/mapper/truecrypt2 /mnt/temp
# mount

Create a test files within the volume, something like this:
# cd /mnt/temp
# vim testfile.txt
(add content for later verification of non-corruption)
# cp -Rp /home/someuser/somedir ./
# cd /mnt

D) Umount/unmap and mount/map the encrypted volume a few times to ensure truecrypt is working smoothly:
# truecrypt -d /dev/mapper/truecrypt2
# truecrypt -l  # (truecrypt2 should no longer be listed.  Kernel module may have unloaded if no other mounted volumes were present.)
# modprobe truecrypt
# truecrypt --device-number 3 --filesystem reiserfs test-vol.tc /mnt/temp
# mount  # (ensure filesystem is up)

Validate files inside of encrypted volume:
# cd /mnt/temp
# cat *  # (verify content as desired)
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gtgentoo@tassone.net</who>
            <bug_when>2006-06-23 11:58:24 0000</bug_when>
            <thetext>Any word on this?  I&apos;ve done a VERY LARGE amount of arch testing for amd64 on this, with zero problems to report.  Can&apos;t we get this keyword added?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gtgentoo@tassone.net</who>
            <bug_when>2006-08-01 14:17:36 0000</bug_when>
            <thetext>BUMP:  This has been sitting for almost a month now with no progress.  I&apos;ve done further (heavy) testing on the amd64 arch since submitting this with no new issues to report.

Please add the appropriate keyword to this package for us amd64 folks.  Thanks...</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>evanderleun@hal9000.nl</who>
            <bug_when>2006-08-22 05:18:24 0000</bug_when>
            <thetext>No problems whatsover, found on my amd64 platform

tested with images on 2 usbsticks
tested with complete devices
tested with truecrypt systems generated on windows and tested on linux and vice versa.

I&apos;m all for adding the amd64 keyword :) </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>b33fc0d3@gentoo.org</who>
            <bug_when>2006-08-22 06:08:52 0000</bug_when>
            <thetext>Tested on amd64, compiles and works as expected (comment #5).</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>b33fc0d3@gentoo.org</who>
            <bug_when>2006-08-22 06:10:19 0000</bug_when>
            <thetext>Created an attachment (id=94861)
emerge.info

emerge --info</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>tcort@gentoo.org</who>
            <bug_when>2006-08-22 06:19:25 0000</bug_when>
            <thetext>done</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>94861</attachid>
            <date>2006-08-22 06:10 0000</date>
            <desc>emerge.info</desc>
            <filename>emerge.info</filename>
            <type>text/plain</type>
            <data encoding="base64">R2VudG9vIEJhc2UgU3lzdGVtIHZlcnNpb24gMS42LjE1ClBvcnRhZ2UgMi4xLXIxIChkZWZhdWx0
LWxpbnV4L2FtZDY0LzIwMDYuMCwgZ2NjLTMuNC42LCBnbGliYy0yLjMuNi1yNCwgMi42LjE3LWVt
aXNzaW9uNiB4ODZfNjQpCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09ClN5c3RlbSB1bmFtZTogMi42LjE3LWVtaXNzaW9uNiB4
ODZfNjQgQU1EIEF0aGxvbih0bSkgNjQgUHJvY2Vzc29yIDMwMDArCmFwcC1hZG1pbi9lc2VsZWN0
LWNvbXBpbGVyOiBbTm90IFByZXNlbnRdCmRldi1sYW5nL3B5dGhvbjogICAgIDIuNC4zLXIxCmRl
di1weXRob24vcHljcnlwdG86IDIuMC4xLXI1CmRldi11dGlsL2NjYWNoZTogICAgIFtOb3QgUHJl
c2VudF0KZGV2LXV0aWwvY29uZmNhY2hlOiAgW05vdCBQcmVzZW50XQpzeXMtYXBwcy9zYW5kYm94
OiAgICAxLjIuMTcKc3lzLWRldmVsL2F1dG9jb25mOiAgMi4xMywgMi41OS1yNwpzeXMtZGV2ZWwv
YXV0b21ha2U6ICAxLjRfcDYsIDEuNSwgMS42LjMsIDEuNy45LXIxLCAxLjguNS1yMywgMS45LjYt
cjIKc3lzLWRldmVsL2JpbnV0aWxzOiAgMi4xNi4xLXIzCnN5cy1kZXZlbC9nY2MtY29uZmlnOiAx
LjMuMTMtcjMKc3lzLWRldmVsL2xpYnRvb2w6ICAgMS41LjIyCnZpcnR1YWwvb3MtaGVhZGVyczog
IDIuNi4xMS1yMgpBQ0NFUFRfS0VZV09SRFM9ImFtZDY0IgpBVVRPQ0xFQU49InllcyIKQ0JVSUxE
PSJ4ODZfNjQtcGMtbGludXgtZ251IgpDRkxBR1M9Ii1tYXJjaD1hdGhsb242NCAtTzIgLXBpcGUi
CkNIT1NUPSJ4ODZfNjQtcGMtbGludXgtZ251IgpDT05GSUdfUFJPVEVDVD0iL2V0YyAvdXNyL3No
YXJlL1gxMS94a2IgL3Vzci9zaGFyZS9jb25maWciCkNPTkZJR19QUk9URUNUX01BU0s9Ii9ldGMv
ZW52LmQgL2V0Yy9lbnYuZC9qYXZhLyAvZXRjL2djb25mIC9ldGMvamF2YS1jb25maWcvdm1zLyAv
ZXRjL3JldmRlcC1yZWJ1aWxkIC9ldGMvdGVybWluZm8gL2V0Yy90ZXhtZi93ZWIyYyIKQ1hYRkxB
R1M9Ii1tYXJjaD1hdGhsb242NCAtTzIgLXBpcGUiCkRJU1RESVI9Ii91c3IvcG9ydGFnZS9kaXN0
ZmlsZXMiCkZFQVRVUkVTPSJhdXRvY29uZmlnIGRpc3Rsb2NrcyBtZXRhZGF0YS10cmFuc2ZlciBz
YW5kYm94IHNmcGVybXMgc3RyaWN0IHVzZXJwcml2IHVzZXJzYW5kYm94IgpHRU5UT09fTUlSUk9S
Uz0iaHR0cDovL2Rpc3RmaWxlcy5nZW50b28ub3JnIGh0dHA6Ly9kaXN0cm8uaWJpYmxpby5vcmcv
cHViL2xpbnV4L2Rpc3RyaWJ1dGlvbnMvZ2VudG9vIgpMQ19BTEw9ImVuX0dCLlVURi04IgpQS0dE
SVI9Ii91c3IvcG9ydGFnZS9wYWNrYWdlcyIKUE9SVEFHRV9SU1lOQ19PUFRTPSItLXJlY3Vyc2l2
ZSAtLWxpbmtzIC0tc2FmZS1saW5rcyAtLXBlcm1zIC0tdGltZXMgLS1jb21wcmVzcyAtLWZvcmNl
IC0td2hvbGUtZmlsZSAtLWRlbGV0ZSAtLWRlbGV0ZS1hZnRlciAtLXN0YXRzIC0tdGltZW91dD0x
ODAgLS1leGNsdWRlPScvZGlzdGZpbGVzJyAtLWV4Y2x1ZGU9Jy9sb2NhbCcgLS1leGNsdWRlPScv
cGFja2FnZXMnIgpQT1JUQUdFX1RNUERJUj0iL3Zhci90bXAiClBPUlRESVI9Ii91c3IvcG9ydGFn
ZSIKUE9SVERJUl9PVkVSTEFZPSIvb3ZlcmxheSIKU1lOQz0icnN5bmM6Ly9yc3luYy5nZW50b28u
b3JnL2dlbnRvby1wb3J0YWdlIgpVU0U9ImFtZDY0IFggYXZpIGJlcmtkYiBiaXRtYXAtZm9udHMg
Y2xpIGNyeXB0IGRsbG9hZGVyIGRyaSBlZHMgZW1ib3NzIGVuY29kZSBmb29tYXRpY2RiIGZvcnRy
YW4gZ2lmIGdub21lIGdwbSBnc3RyZWFtZXIgZ3RrMiBpbWxpYiBpcHY2IGlzZG5sb2cganBlZyBr
ZGUgbHp3IGx6dy10aWZmIG1wMyBtcGVnIG5jdXJzZXMgbmxzIG5wdGwgb3BlbmdsIHBhbSBwY3Jl
IHBkZmxpYiBwZXJsIHBuZyBwcHBkIHB5dGhvbiBxdDMgcXQ0IHF1aWNrdGltZSByZWFkbGluZSBy
ZWZsZWN0aW9uIHNkbCBzZXNzaW9uIHNwZWxsIHNwbCBzc2wgdGNwZCB0aWZmIHRydWV0eXBlLWZv
bnRzIHR5cGUxLWZvbnRzIHVzYiB4b3JnIHhwbSB4diB6bGliIGVsaWJjX2dsaWJjIGlucHV0X2Rl
dmljZXNfa2V5Ym9hcmQgaW5wdXRfZGV2aWNlc19tb3VzZSBrZXJuZWxfbGludXggdXNlcmxhbmRf
R05VIHZpZGVvX2NhcmRzX2R1bW15IgpVbnNldDogIENUQVJHRVQsIEVNRVJHRV9ERUZBVUxUX09Q
VFMsIElOU1RBTExfTUFTSywgTEFORywgTERGTEFHUywgTElOR1VBUywgTUFLRU9QVFMsIFBPUlRB
R0VfUlNZTkNfRVhUUkFfT1BUUwoK
</data>        

          </attachment>
    </bug>

</bugzilla>