Comments (13)
On the idea of using set instead of list for Keys: this does not currently work as Key is not hashable. We could easily make them hashable though
from python-tuf.
For tuf-on-ci use case I want:
- list of keys that have signed correctly
- list of keys that have not signed (I don't care if the sig is missing or incorrect)
- has threshold been reached
Things that I don't care that much about:
- the actual signatures (easy to lookup with keys if needed)
- threshold (easy to lookup)
- number of good sigs (easy to calculate)
so from my POV something like this:
@dataclass
class SigningStatus:
verified: bool
signed_keys: list[Key]
unsigned_keys: list[Key]
def delegate_signing_status(
delegated_role: str,
delegated_metadata: "Metadata",
signed_serializer: Optional[SignedSerializer] = None
) -> SigningStatus:
from python-tuf.
I think returning set of keyids is ok and fits the rest of the API.
If someone wants to take the WIP commit above and polish, I'm totally fine with that.
As a note on the implementation, I originally included threshold in the result but decided against that: A useful operation is to "union" two VerificationResults (in the root case) and I think providing that in the library might be good... Two thresholds however cannot be "unioned".
from python-tuf.
Use cases:
- RSTUF: repository-service-tuf/repository-service-tuf-worker#367 (cc @MVrachev, @kairoaraujo)
- tuf-on-ci: ?? (cc @jku)
from python-tuf.
One additional related use case I saw in both tuf-on-ci and RSTUF:
- is a given signature valid for delegate according to delegator?
It's easy enough to implement in the application. I'm bringing it up here, because, if delegate_signing_status
returns the valid signatures, it could be used for that purpose. OTOH, the validity of a given signature might be interesting by itself, regardless of other signatures. So maybe we should treat this as separate feature. Any thoughts?
from python-tuf.
Re name: I'm a bit unhappy with the verb/noun ambiguity of delegate. delegate_signing_status
, to me, sounds like the activity of delegating the signing status, for whatever that means. But I'm okay, if we clarify this in the docstring.
from python-tuf.
is a given signature valid for delegate according to delegator?
It could be I just don't remember the specific location but I think tuf-on-ci question is (or should be) "has this signing key signed this delegated role?"
I think in 99% of cases applications should not touch or think about the actual signatures at all.
from python-tuf.
It could be I just don't remember the specific location but I think tuf-on-ci question is (or should be) "has this signing key signed this delegated role?"
You are right, I mis-skimmed the code I was referring to. nvm
from python-tuf.
[edit: fixed math after talking to Jussi]
I think Jussi's proposal is complete.
Returning "invalid signatures" as well does not make a lot of sense, because the signatures could be invalid according to one delegator, but valid according to another, which is not unlikely in the case of a root update. So, to get the desired information -- "does the metadata have invalid signatures?" -- we'd need to do set operations on multiple results anyway, and this can be done with the existing fields too. E.g. root update
stat_old = old_root.delegate_signing_status("root", new_root)
stat_new = new_root.delegate_signing_status("root", new_root)
has_invalid_sigs = len(metadata.signatures) > len(stat_old.signed_keys | stat_new.signed_keys) # assume signed_keys is a set of keyids
invalid_sigs = metadata.signatures.keys() - (stat_old.signed_keys | stat_new.signed_keys)
from python-tuf.
Yes, I agree with what you said.
I think I like the unstated assumption in your examples that the key lists are actually sets -- then you can do unions more easily, and I can see that would be useful.
The "math" in your code has some issues but I don't think they're very important:
has_invalid_sigs = len(metadata.signatures) > (len(stat_old.signed_keys) + len(stat_new.signed_keys)) # assume signed_keys is a set of keyids
That's not right (keys might be duplicate and anyway thresholds may be different). Like you said, for root you'd just have to duplicate whatever you do normally to find invalid sigs (whatever "invalid" means in this context): you'd then have two separate lists of "invalid sigs"... unsure what you would want to do with them.
I think there are more useful questions and they seem fairly easy to answer:
- "which root keys have not yet signed correctly, but could still do so":
unsigned_keys = stat_old.unsigned_keys | stat_new.unsigned_keys
- "Which root keys may need to act for the metadata to become verified":
missing_keys = set() if not stat_old.verified: missing_keys |= stat_old.unsigned_keys if not stat_new.verified: missing_keys |= stat_new.unsigned_keys
from python-tuf.
Cross-posting from slack, by "invalid signature" I meant:
- there is no authorized keyid for a signature's keyid in any eligible delegator, or
- there is an authorized keyid but no public key in the corresponding keystore, or
- there is an authorized keyid and a public key but verification fails cryptographically
I edited my "math" in the comment above to correctly support these checks
from python-tuf.
On the idea of using set instead of list for Keys: this does not currently work as Key is not hashable. We could easily make them hashable though
Or maybe not: hashable objects are not supposed to be mutable (the hash should be a constant for the lifetime of the object). Strictly speaking that's not true for Keys even if our keys almost never mutate. We could return keyids instead of keys to get around this. Then my use case is still reasonable if not anymore trivial:
status = root.delegate_signing_status("timestamp", timestamp_metadata)
signed = [root.get_key(id) for id in status.signed_keys]
Or we could just say the Keys are immutable enough so that we can put them in this short lived set 🤷
from python-tuf.
Or we could just say the Keys are immutable enough so that we can put them in this short lived set 🤷
Hm, I suppose it's okay, if we document the caveat. Alternatively, we could implement a custom key container, which provides all the desired set operations for contained Key objects. And which clearly documents that mutating the items breaks the container.
from python-tuf.
Related Issues (20)
- tests: remove obsolete test metadata HOT 1
- repository: redesign needed after recent verify_delegate changes
- build: Enable python 3.12 HOT 4
- investigate alternative hatchling version pinning HOT 2
- Consider including `securesystemslib[crypto]` as a dependency in TUF HOT 5
- VerificationResult should include keys for keyids HOT 4
- Replace most linting tools with ruff HOT 1
- repository: maybe provide a Repository.get_delegating_role() HOT 2
- Yearly maintainer permissions review HOT 1
- Change `securesystemslib.dsse.Envelope.signatures` to dict upstream HOT 2
- Test all components with DSSE
- Test "ruff check --output-format=github" HOT 2
- linting: Enable more ruff rulesets HOT 7
- linting: enable pycodestyle for tests
- datetime.utcnow() is deprecated: stop using it HOT 1
- SimpleEnvelope._DEFAULT_PAYLOAD_TYPE should be public? HOT 2
- should build job require prior test job to pass? HOT 3
- possible blog post: Caching TUF metadata HOT 3
- provide user-agent customization?
- workflows: macos runners are missing older pythons
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-tuf.