| # Repository-less conda signature verification | |
| # conda handles this process for you if you're using the repository; however, | |
| # if you need to perform this process locally with files obtained another way, | |
| # you can follow the instructions explained below to run appropriate shell | |
| # commands. | |
| # | |
| # We should add a command-line option for conda to perform this process for | |
| # you, but this should work in the interim. | |
| # |
| from pprint import pprint | |
| from conda_content_trust.common import load_metadata_from_file, SignatureError | |
| from conda_content_trust.authentication import verify_delegation | |
| from conda_content_trust.signing import wrap_as_signable | |
| def check_all_artifacts_in_repodata(repodata_fname, trusted_key_mgr_fname): | |
| trusted_key_mgr = load_metadata_from_file(trusted_key_mgr_fname) | |
| repodata = load_metadata_from_file(repodata_fname) |
| class MixinKey(): | |
| """ | |
| This is a mix-in (https://www.ianlewis.org/en/mixins-and-python) for the | |
| PrivateKey and PublicKey classes, specifically. It provides some | |
| convenience functions. | |
| """ | |
| def to_bytes(self): | |
| """ | |
| Pops out the nice, tidy bytes of a given ed25519 key object, public or | |
| private. |
| """ | |
| <Purpose> | |
| This function provides a list of verified target info. | |
| It will start with all the targets listed by the currently trusted | |
| version of role rolename. It will then call get_one_valid_targetinfo to | |
| walk the targets delegation graph in order to provide only verified | |
| target info for the targets listed. | |
| As a result: |
| -- Note that maximum lengths can be assigned to SEQUENCES. | |
| RootModule DEFINITIONS AUTOMATIC TAGS ::= BEGIN | |
| EXPORTS RootMetadata; | |
| IMPORTS | |
| Keyids, | |
| Length, | |
| Version, |
| REPRESENTATION 1: | |
| <Arguments> | |
| vin See class docstring above. The VIN of a Secondary | |
| in this vehicle submitting an ECU Manifest is | |
| expected to be the same as the VIN for this Primary. | |
| (In deployments where a Primary is shared -- for | |
| example, a dealer device connected directly to a | |
| vehicle for manual updates/modifications -- some |
1. MAC:
2. Room, Building
3. Name- NetID:
4. Device and OS
#RFC: Multi-Role Delegation (Alternative, Normalized Design)
Note that the following differs from RFC: Multi-Role Delegation in that it decouples roles from delegations not just for multi-role delegations but for all delegations. Unlike the previous design, it is not inherently backwards compatible, and it requires a bit more tinkering in the code.
##Motivation Currently, TUF delegations are limited to requiring a threshold number from one group of keys. Sometimes, a repository manager may want to provide a more elaborate set of requirements for who must sign a set of files.
Suppose there is a directory of targets in the repository that should be signed both by two keys from group A (developer keys, say) and by a key from group B (a change manager's key, say). That (requiring X keys out of group A and Y keys out of group B) is not currently possible in TUF.
An addition to the TUF spec is warranted to allow for this kind of complex
#RFC: Multi-Role Delegation
##Motivation Currently, TUF delegations are limited to requiring a threshold number from one group of keys. Sometimes, a repository manager may want to provide a more elaborate set of requirements for who must sign a set of files.
Suppose there is a directory of targets in the repository that should be signed both by two keys from group A (developer keys, say) and by a key from group B (a change manager's key, say). That (requiring X keys out of group A and Y keys out of group B) is not currently possible in TUF.
An addition to the TUF spec is warranted to allow for this kind of complex trust arrangement.
##Proposal