Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#80 Support multiple checksum array for each transcript line

UNIX (32)

- Summary
Provide a descriptive summary of the issue.
- Update the Radmind transcript format to support an array of
multiple checksum types on each transcript line.
- Steps to reproduce
In numbered format, detail the exact steps taken to produce the
- n/a
- Expected results
Describe what you expected to happen when you executed the steps
- The transcript format would be revised to support an array of
checksums for each file, possibly with a master checksum that
corresponds to today's single checksum hash.
- Actual results
Please explain what actually occurred when steps above are
- The Radmind tools as of version 1.11.1 support only a single
checksum per transcript line.
- This limits the longevity of transcripts created today and may
make upgrades to newer hashing algorithms more difficult over
- Regression
Describe circumstances where the problem occurs or does not
occur, such as software versions and/or hardware configurations.
- n/a
- Notes
Provide additional information, such as references to related
problems, workarounds and relevant attachments.
- In supporting multiple checksum types in an array on each
transcript line, the Radmind tools could become more flexible for
future expansion. New checksum types could be enabled over time,
in much the way that new encryption types have been added to
- There could be a primary checksum, which could correspond to
today's checksum field.
- The additional checksums could also be used during fsdiff. While
this would be compute- and I/O-intensive, it would provide
additional assurance that an attacker has not replaced a file
with an alternative that takes advantage of the slim chance of
breaking a single checksum. It is unlikely that an attacker could
create a single alternate file that would pass checksumming with
two or more different hashing algorithms. This type of scan could
be used by paranoid administrators for more sensitive files, such
as core operating system or kernel files files.
- The tools may then need to be revised to support a minimum and/or
maximum checksum type, in similar fashion to how gzip compression
is handled between Radmind client and server today.
- The tools may also need to handle the situation where mixed
checksum types are used, depending on the transcript line
compared against (especially if a primary checksum field and an
array are both listed for each transcript line). I am ignorant of
the compute power needed for various types of checksums, but this
may allow the mixing and matching of checksums so that less
intensive ones can be used for less important files, based on the
desires of the administrator.
- System configuration
Include the current system configuration of each computer that
experienced the problem.
- n/a


  • Logged In: YES
    Originator: NO

    "The Radmind tools as of version 1.11.1 support only a single checksum per transcript line. This limits the longevity of transcripts created today and may make upgrades to newer hashing algorithms more difficult over time."

    Huh? All you need to do is run lcksum -c new_hash_algorithm on the transcript and all checksums are updated based on the algorithm of your choice.

    "[long justification for array of checksums]"

    While I don't like the idea of appending additional fields to the transcript line, we (the Radmind developers) have discussed multiple checksum support in the past. There'd still be only one field for the checksum, but the value would be the combination of the resulting checksums for each algorithm requested by the admin. I'm not going to say it has a high priority at the moment, but it's on the list.

  • Patrick McNeal
    Patrick McNeal

    Logged In: YES
    Originator: NO

    I could see this as being included when transcript lines are expanded to support other types of meta data. Maybe in this format:


    where key is a "registered" radmind data key, and the value is a RAP safe string. For checksums, this might look like:

    f ./test 0644 502 20 1215465136 0 sha1:2jmj7l5rSw0yVb/vlWAYkK/YBwk= md5:1B2M2Y8AsgTpgAmY7PhCfg== ripemd160:nBGFpcXp/FRhKAiXfuj1SLIljTE=

    ( That's one long line. )

  • Patrick McNeal
    Patrick McNeal

    • labels: --> UNIX
    • milestone: --> v2.x
  • Jaharmi

    Logged In: YES
    Originator: YES

    I originally brought this up on one of the Radmind lists a few years ago, but I never made a formal request for the tracker. So, I thought I'd do it now.

    While I understand that lcksumming transcripts is an option, it doesn't necessarily provide a lot of dynamic configuration options. It also means that you're changing all of your transcripts, which could be considered destructive -- and somewhat at odds with allowing for more dynamic configuration. However, I would say that the use of lcksum to modify checksums is a workaround today.

    I'm fine with a key/value pair or any other method that allows for one or more checksums (with the possibility of future expansion), for what it's worth.

    And, also, I can't say that I consider this a high priority but I'd put it on my "nice to have" list, especially if a revision to the transcript format is being considered at some point anyway.

  • Patrick McNeal
    Patrick McNeal

    Logged In: YES
    Originator: NO

    Set to lower priority for v2.

  • Patrick McNeal
    Patrick McNeal

    • priority: 5 --> 3