-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion of TAP 6: Include specification version in metadata #35
Comments
An issue with TAP 6 was raised here (it forces parsing of untrusted metadata). |
So @heartsucker raised a good point. @endophage, what are your thoughts? |
The other point we need to define is how clients are supposed to deal with metadata of different versions. Are they supposed to only accept exactly the version they were written for? Should they have rules about what to ignore and what to use? |
Yeah, I don't know how to address the need to parse at least some of the JSON. I don't think putting it in the URL/path is the right solution for two reasons:
It's an imperfect solution but maybe we can have the |
Yes, I tend to agree that a URL / path isn't the right way to handle this.
The version number clearly needs to be protected.
How concerned are we all about the need to parse at least some JSON? I
don't feel this is a deal breaker. Does anyone feel is it adequate to just
make implementers aware of this issue?
…On Fri, Aug 18, 2017 at 4:05 PM, David Lawrence ***@***.***> wrote:
Yeah, I don't know how to address the need to parse at least some of the
JSON. I don't think putting it in the URL/path is the right solution for
two reasons:
1. That should be reserved for potential changes to how pathing is
performed (i.e. the API to access the TUF files).
2. The version should be signed to ensure an attacker can't change the
version and for example, set it to an older mode that causes some newer
piece of verification to not be performed.
It's an imperfect solution but maybe we can have the spec_version only
apply to the signed component and be included in there? Then it can be
parsed like the expires, and version fields after signature verification.
My instinct is that the signed section will be the location of most spec
changes while signatures will see very little iteration.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#35 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0XD2adguRNWTgMJQT7HeK-lbWFwJStks5sZe5_gaJpZM4NsGRX>
.
|
I also feel that the "signed" portion of metadata is the best place to store "spec_version." Parsing untrusted JSON/metadata is a separate issue in my opinion, and we should deal with it in a separate TAP/issue. Parsing untrusted data is a problem for all of the other keys in "signed," as well. Perhaps the solution is signing the "signed" portion as it is written to disk/file, or maybe the base64 string is the best option... Nevertheless, we should discuss this issue elsewhere. Does anyone not agree? May I go ahead and accept TAP 6 if there is no other disagreement? |
This should be fine as the signature verification would happen first, and then we'd check the |
Okay, I've proposed a PR to accept this TAP.
Justin
…On Fri, Aug 25, 2017 at 11:46 AM, heartsucker ***@***.***> wrote:
How concerned are we all about the need to parse at least some JSON?
This should be fine as the signature verification would happen first, and
then we'd check the spec_version field like we check the expires and
other fields. I agree with @endophage <https://github.com/endophage> that
the signatures portion is unlikely to see iteration after TAP 9. With
that change, each signature object contains the absolute minimum amount of
data necessary to check a signature, so it (hopefully) won't change again.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#35 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0XD1Sk3s2jRTDxZvQLumGx8JdXqG-dks5sbuxDgaJpZM4NsGRX>
.
|
PR has been merged. Closing this issue now that TAP 6 has been accepted! |
TAP 6 is available at https://github.com/theupdateframework/taps/blob/master/tap6.md
Pull requests related to TAP 6:
#18
Discussion of TAP 6 on the TUF mailing list:
https://groups.google.com/d/msg/theupdateframework/iDdRsl-gUII/4N9xVahdAwAJ
The text was updated successfully, but these errors were encountered: