Cannot add signing key if the key's keyid_hash_algorithms list isn't exactly equal to tuf.conf.REPOSITORY_HASH_ALGORITHMS

[awwad]

This bug is a little strange - I'm not sure why this would be yet.

Hypothesis:
If you try to add a signing key (..load_signing_key(), from tuf.repository_tool), then unless the signing key in question has the same keyid_hash_algorithms list (e.g. ['sha256', 'sha512']) as the value of tuf.conf.REPOSITORY_HASH_ALGORITHMS (e.g. ['sha256']), then the signing key will silently not be added. No error is raised by the load_signing_key call. repository.status() will report that there has not been a key added, and write() will fail (if other keys added aren't adequate without the mismatched-hash-algorithms key).

To reproduce the bug, generate a key (or take a key already generated previously by repository_tool), THEN change tuf/conf.py to set REPOSITORY_HASH_ALGORITHMS to exclude sha512 (['sha256'] instead of ['sha256', 'sha512']), and then create a repository and try loading the key as described above.

Several debugging pathways were not explored: the constraint may not be that the lists must be equal, but the case provided above fails when it should not.

(I ran into this while trying to cut down the size of Targets metadata for Uptane for Partial Verification Secondaries. By default, both SHA256 and SHA512 hashes are listed for fileinfo.)

[vladimir-v-diaz]

I reproduced this bug in the latest codebase. Let me try to figure out what's happening, and will then fix it on the master branch.

[vladimir-v-diaz]

Since the keyid_hash_algorithms attribute is saved to Root, modifying this attribute later (via tuf.settings) might cause a mismatch. I'll determine what we should do to address this limitation.

[vladimir-v-diaz]

@awwad and I went over different solutions for how to add and modify keyid_hash_algorithms. For instance, should it be a global Root setting? Configuration setting? Argument? During brainstorming, we concluded that the keyid_hash_algorithms attribute probably shouldn't be included in the key object since keyids would be invalidated if the user repository / user were to change it. Removing this attribute from the key object would likely fix this issue, so I'll make this change first.

[vladimir-v-diaz]

This branch excludes the keyid_hash_algorithms attribute when generating a KEYID. Modifying keyid_hash_algorithms would cause the KEYID of a key to unexpectedly change.
The snippet below demonstrates the expected behavior.

>>> from tuf.repository_tool import *
>>> repo = load_repository('repository')
>>> import securesystemslib.settings
>>> securesystemslib.settings.HASH_ALGORITHMS
[u'sha256', u'sha512']
>>> securesystemslib.settings.HASH_ALGORITHMS = ['sha512']
>>> root_key = import_rsa_privatekey_from_file('keystore/root_key', 'password')
>>> repo.root.load_signing_key(root_key)
>>> repo.status()
u'root' role contains 1 / 1 signatures.
u'targets' role contains 0 / 1 signatures.
>>> 

[vladimir-v-diaz]

This branch now includes (in the "roles" field of metadata) a key's full list of keyids.

"targets": {
    "keyids": [
     "1e86cd03e2a8e5210c423b6366058651f3032d96f0b63055feafb1694c294be9",
     "bcca77b84ffdd344efbae46dd224e165af2be1264c615c96418236454dfed1763cef61be1cb19cd725edf2b59bcce08a46ab7715f3c96800ede669a30b6f5ca6"
    ],
    "threshold": 1
},

However, I'm not entirely convinced yet of this change. Will do more testing.

[vladimir-v-diaz]

We should also make it clear in the specification that only unique keys should be counted when processing signatures in metadata. It is possible to unexpectedly satisfy a threshold of signatures by including multiple, valid KEYIDs in metadata (same key, but different keyids due to multiple hash algorithms being used by the repository. It is also possible to generate multiple, different RSA-PSS signatures with the same RSA key.

This commit tries to prevent duplicate keys.

[awwad]

What's the status of these commits / issue?

[awwad]

See #442

[jku]

Closing this issue as it was filed against (what is now known as) the legacy codebase: issue seems to not be relevant anymore. Please re-open or file a new issue if you feel that the issue is revelant to current python-tuf.

More details

Current source code (and upcoming 1.0 release) only contains the modern components

• a low-level Metadata API (tuf.api) and
• tuf.ngclient that implements the client workflow,

Legacy components (e.g. tuf.client, tuf.repository_tool, tuf.repository_lib as well as the repo and client scripts) are no longer included. See announcement and API reference for more details.