profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/mnm678/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

Fakesbook/Fakesbook 5

A teaching platform designed to enable visualization of social networking graphs and data privacy.

mnm678/CSStudyInstruments 0

CSStudyInstruments

mnm678/deployment-considerations 0

Deployment Considerations and Best Practices for Uptane

mnm678/go-flags 0

go command line option parser

Pull request review commenttheupdateframework/specification

Rollback attacks and fast forward recovery

 it in the next step.   report the potential freeze attack.  On the next update cycle, begin at step   [[#update-root]] and version N of the root metadata file. -11. **If the timestamp and / or snapshot keys have been rotated, then delete the-  trusted timestamp and snapshot metadata files.** This is done-  in order to recover from fast-forward attacks after the repository has been-  compromised and recovered. A *fast-forward attack* happens when attackers-  arbitrarily increase the version numbers of: (1) the timestamp metadata, (2)-  the snapshot metadata, and / or (3) the targets, or a delegated targets,-  metadata file in the snapshot metadata. Please see [the Mercury-  paper](https://theupdateframework.io/papers/prevention-rollback-attacks-atc2017.pdf)-  for more details.+11. **Fast-forward attack recovery** A _fast-forward attack_ happens+  when attackers arbitrarily increase the version numbers in any of the+  timestamp, snapshot, targets, or delegated targets metadata. The attacker's goal+  is to cause clients to refuse to update the metadata later because the attacker's+  listed metadata version number (possibly MAX_INT) is greater than the new valid+  version.  To recover from a fast-forward attack after the repository has been+  compromised and recovered, certain metadata files need to be deleted as+  specified in this section. If a targets file is subjected to a+  fast-forward attack, the snapshot role's keys should be replaced. Please see+  [the Mercury paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf)+  for more details on fast-forward attacks.++    1. **Snapshot recovery** If the trusted snapshot metadata cannot be+    validated using a threshold of snapshot keys from the new trusted root+    metadata, delete the trusted snapshot and timestamp metadata+    files.

I agree that we should separate back out the timestamp vs snapshot recovery. Looking at it again, I actually don't think this check is in the right place in the workflow. I think the timestamp recovery should happen when the timestamp is downloaded, not as part of the root metadata workflow, and the same for snapshot. Especially as it is no longer tied to anything in the previous root metadata file.

It would be great to have separate documentation for the repository workflow. Right now all the advise for managing a fast forward attack (and a lot of other pieces) is buried here in the client workflow.

mnm678

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

issue commenttheupdateframework/specification

Delineating between security property requirements and internal consistency requirements in detailed client workflow

It could be helpful if the specification explicitly delineated between these two types of requirement so that implementers can more easily make informed decisions. In many cases the delineation is implicit (through use of RFC 2119 keywords on pieces of the detailed client workflow related to TUF security properties), but more explicit notation/annotations would make it easier for integrators to adopt TUF safely.

I think part of this effort should be to make more formal use of the RFC 2119 keywords (ie MUST/SHALL for security critical features, SHOULD for features that are recommended, MAY for suggestions). This approach as worked well for Uptane in helping define Uptane compliance.

joshuagl

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commenttheupdateframework/taps

Discussion of TAP 14: Managing TUF Versions

I haven't actually worked with delegated targets yet, so I don't have much intuition with them yet. Maybe we could have an analogous spec version field in the targets metadata for them? This could allow the core metadata to migrate first, but allow delegated targets to take more time to migrate.

That could work. And it could be an optional field that's only used if the delegated targets are or could be out of sync with the top-level metadata.

By "version 3 and version 4", do you mean the spec versions for these files, or the metadata versions? Maybe we need another name for this. What if we used the terminology "epoch" or "tuf spec epoch" to avoid this ambiguity? I've seen this used elsewhere.

I agree. I'll update this in my next pass on the TAP. I try to be careful about saying "tuf spec version", but clearly I sometimes forget to type the whole thing :).

Anyway, presuming you are referring to tuf spec version / tuf spec epoch, I see this as something that always goes forward in time. We always want to use the latest supported tuf spec version / epoch version that's available. So I'd assume these paths would be 3.0.0/5.snapshot.json and 4.0.0/5.snapshot.json.

Ok, so you can still use the directory structure, just not browse all of them. That makes sense.

Also, coming over from #138, a repository migrating from one POUF to another can break clients, even if the semantics of the TUF spec stay the same. For example, switching from json to DSSE, and maybe down the road to the binary COSE format. Would it make sense to consider a repository version / epoch as well, or in replacement for supporting TUF spec version changes? Having this under repo control could allow for more radical changes like this.

With the name change to "epoch", I think it makes sense to tie this to either a POUF or tuf spec version change. That way we won't need another mechanism for when the POUF is updated. It also makes philosophical sense, in that the interoperability is tied to the POUF rather than the spec version. I don't think this requires any technical changes to the TAP, but maybe some new framing.

mnm678

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentsigstore/root-signing

Fix expiration time by using UTC time according to spec

 func InitCmd(directory string, targets targetsFlag) error { 	if err != nil { 		return err 	}-	expiration := time.Now().AddDate(0, 6, 0)+	expiration := time.Now().AddDate(0, 6, 0).UTC() 	relativePaths := []string{}-	root.Expires = expiration-	root.Version++

Ah, now I see it, thanks

asraa

comment created time in 4 days

PullRequestReviewEvent

Pull request review commenttheupdateframework/go-tuf

Update CLI descriptions and their reference in the README.md file

 the snapshot manifest will expire. Stages an appropriate `timestamp` manifest. If a `snapshot` manifest is staged, it must be fully signed. -#### `tuf sign ROLE`+#### `tuf sign <manifest>`

Can we call this metadata for consistency?

rdimitrov

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentsigstore/root-signing

Fix expiration time by using UTC time according to spec

 func InitCmd(directory string, targets targetsFlag) error { 	if err != nil { 		return err 	}-	expiration := time.Now().AddDate(0, 6, 0)+	expiration := time.Now().AddDate(0, 6, 0).UTC() 	relativePaths := []string{}-	root.Expires = expiration-	root.Version++

I don't see this version increment moved somewhere else, is it not needed?

asraa

comment created time in 4 days

PullRequestReviewEvent

issue commentnotaryproject/tuf

Accessing TUF metadata on a registry

I made a diagram based on this discussion and the discussion in the meeting showing where TUF metadata could be stored using the artifact references where possible. It has the delegated targets metadata stored alongside the artifact, and a separate repository for root and top-level targets metadata. I imagine that snapshot and timestamp metadata could also be added to the TUF repository.

One thing missing from this diagram is how the client knows where the TUF repository is. The client will need to establish trust in the root keys using an external process, so it might make sense to distribute the tuf repository location at the same time?

tuf-notary repository setup(1)

If the artifact is moved to a new registry, the user could continue to download the TUF metadata from the original repository, or they could use a different TUF metadata repository on the new registry.

mnm678

comment created time in 5 days

push eventmnm678/specification

Jussi Kukkonen

commit sha 4d69ee9e11c01ba6d6ea9485a84b0c79e20223c8

Require role name uniqueness in delegations delegations must be unique by role name: otherwise we end up in a situation where a delegation to a delegated role could be valid and invalid at the same time, depending on the path or path_hash_prefix. This matches the treatment in root where roles is an actual dictionary, ensuring uniqueness by role name.

view details

Jussi Kukkonen

commit sha c7809e816a78a47cb85d0a76138f4a9eb363d83f

Require keyid uniqueness in metadata signatures list Allowing multiple signatures per keyid is not useful and makes it easier to make an implementation mistake and count a single key multiple times in threshold calculation.

view details

Jussi Kukkonen

commit sha 2ccb90268c6a606d48e36b144dabbc81b71332cf

Update version to 1.0.20

view details

Marina Moore

commit sha 887263ea9ec32b648fc348d1bec7b53dc2f9df9c

Merge branch 'master' into unique-delegated-role-names

view details

Joshua Lock

commit sha c6c985aec40d6f79db437f270ac96825da730dac

Merge pull request #166 from jku/unique-delegated-role-names Add notes on uniqueness of keyids and role names

view details

Joshua Lock

commit sha 7544c414ed5046d3fb1bec518ba5525ff9280a08

Remove redundant MUST statement in "Update the root role" In 5.3.1 of the detailed client workflow, it is not necessary to say that the client MUST temporarily turn on consistent snapshots -- the following subsections of 5.3 describe the expected behaviour. Signed-off-by: Joshua Lock <jlock@vmware.com>

view details

Joshua Lock

commit sha adeaea4147a6e480df46b1060c24463f87f1827e

Remove outdated terminology from description of ROLE Each of the top-level roles must be specified as a field in the "roles" object. Signed-off-by: Joshua Lock <jlock@vmware.com>

view details

Joshua Lock

commit sha 04b284723ac53aae489be73a18ddf3306c356803

Fix bikeshed markup Change 4d69ee9e11c01ba6d6ea9485a84b0c79e20223c8 used the wrong Bikeshed syntax to link to an existing defined term. Fix that. Signed-off-by: Joshua Lock <jlock@vmware.com>

view details

Marina Moore

commit sha 77e53c75b566980950cb0d2a4b7999d8fb328e25

Merge pull request #180 from joshuagl/joshuagl/fix-bs Fix build breakage on master

view details

asraa

commit sha 57f636edfbe3aeb247ab30cef85b526f407a0f4e

Add guidance about unknown fields (#169) * remove autoformat Signed-off-by: Asra Ali <asraa@google.com> * update date Signed-off-by: Asra Ali <asraa@google.com> * update with suggested fix Signed-off-by: Asra Ali <asraa@google.com> * Update tuf-spec.md Co-authored-by: Joshua Lock <jlock@vmware.com> Co-authored-by: Marina Moore <mnm678@users.noreply.github.com> Co-authored-by: Joshua Lock <jlock@vmware.com>

view details

Martin Vrachev

commit sha 8dafd00b8fde4512d1799f9dcc41c77d8dd9d0e1

Clarify optional attributes (#165) * Clarify that delegations are optional Nowhere in the spec, we clarify that "delegations" is an optional field in the targets metadata file. This is a possible reason why (at the time of writing this commit) in the TUF python reference implementation "delegations" is still a required field. Signed-off-by: Martin Vrachev <mvrachev@vmware.com> * Make CONSISTENT_SNAPSHOT optional From chapter 6.2.1 in the tuf specification (version 1.019) "Finally, the root metadata should write the Boolean "consistent_snapshot" attribute at the root level of its keys of attributes. If consistent snapshots are not written by the repository, then the attribute may either be left unspecified or be set to the False value. Otherwise, it must be set to the True value." The above implies that there could be repositories with root metadata without CONSISTENT_SNAPSHOT. Clarify that, but phrase it so it's clear this should be included in new implementations. For context: https://theupdateframework.github.io/specification/latest/index.html#writing-consistent-snapshots Signed-off-by: Martin Vrachev <mvrachev@vmware.com> * Clarify "paths" and "path_hash_prefixes" Clarify "paths" and "path_hash_prefixes" in delegations, because currently, it's not properly defined which of these options can be used to create a valid target file: - BOTH paths and path_hash_prefixes - ONLY ONE of paths and path_hash_prefixes - NONE of paths and path_hash_prefixes With this change, I aim to define clearly that a valid target file will contain ONLY ONE of them or NONE of them. Signed-off-by: Martin Vrachev <mvrachev@vmware.com> * Update tuf-spec.md Co-authored-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com> Co-authored-by: Joshua Lock <jlock@vmware.com> Co-authored-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com> Co-authored-by: Marina Moore <mnm678@users.noreply.github.com>

view details

Joshua Lock

commit sha 534aa36651f01ea19677c8e3d86cb98490af807d

Build spec during PR workflow (#182) Use bikeshed to build the spec as part of the PR workflow to try and prevent breaking changes being merged. Signed-off-by: Joshua Lock <jlock@vmware.com>

view details

Trishank Karthik Kuppusamy

commit sha 2585a4e10dac7e3dd9663225aa081c1a9114e659

Explain why we check hashes before signatures (#142) * explain why we check hashes before signatures Signed-off-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com> bump version * Update tuf-spec.md Co-authored-by: Joshua Lock <jlock@vmware.com> * Update tuf-spec.md Co-authored-by: Joshua Lock <jlock@vmware.com> Co-authored-by: Joshua Lock <jlock@vmware.com>

view details

Marina Moore

commit sha 5441368c01243d2a302b8f4ada7c2a0f70c03998

Merge branch 'master' into client-verification

view details

push time in 5 days

push eventmnm678/specification

Marina Moore

commit sha e5c0729053a975c0e0cbe151b0c979717bf23a7c

Update tuf-spec.md Co-authored-by: Hossein Siadati <87046468+hosseinsia@users.noreply.github.com>

view details

push time in 5 days

push eventuptane/uptane-standard

Lois Anne DeLong

commit sha 60217072d28b748fbee08cc1481fc803425c6855

Updates and SHALL I added a note that the compliance word for the Standard is to be SHALL, not MUST and updated to the reference links for the standard and deployment documents to 1.2.0

view details

Lois Anne DeLong

commit sha c758fd446ce4348c5aa37e779ed2de0c0bf69ec0

Update uptane-standard.md Per a discussion at our 8/3/21 Uptane Standards meeting, this PR adds the actual RFC 2119 definitions to the Standard, as well as the caution against the use of imperatives from that document.

view details

Marina Moore

commit sha b782e5ece62916d4797be2fe90f2d58af269f6ac

Merge pull request #215 from jhdalek55/patch-10 Version Updates, SHALL Preference, and Added definitions

view details

push time in 5 days

PR merged uptane/uptane-standard

Version Updates, SHALL Preference, and Added definitions

I added a note that the compliance word for the Standard is to be SHALL, not MUST and updated to the reference links for the standard and deployment documents to 1.2.0

+15 -7

7 comments

2 changed files

jhdalek55

pr closed time in 5 days

PullRequestReviewEvent

issue commenttheupdateframework/taps

Discussion of TAP 14: Managing TUF Versions

There are a number of TUF implementations that don't have a traditional filesystem, so I agree that we should consider some alternatives.

I see a few downsides to using a field in root. These may or may not be worth the simplicity of removing the file system structure:

  • If the root metadata format changes (for example #143), a client on an older version may not be able to find the spec versions. It might be alright to limit future changes so that this field must be accessible.
  • Delegated targets would have to change spec versions in sync with the top-level roles. In some implementations, these delegated targets are controlled by different entities, and so this would take some coordination. Major spec version changes should be rare, so this would only be an occasional annoyance.
  • Metadata from different spec versions would need to be discoverable on the repository. If there is a snapshot metadata for both version 3 and version 4, how are these named?
mnm678

comment created time in 5 days

issue commentnotaryproject/notaryproject

How to document notary project content

I agree that option 1 will have a better chance of keeping docs and code in sync.

SteveLasker

comment created time in 5 days

pull request commenttheupdateframework/specification

Rollback attacks and fast forward recovery

@trishankatdatadog @jku I updated the fast-forward attack recovery section. Does this look good to both of you?

mnm678

comment created time in 8 days

push eventmnm678/specification

Marina Moore

commit sha 07a46db99e38263b860fc6184c6d1d4bc12a6c7b

Simplify fast-forward attack recovery Require that the snapshot keys are replaced for fast-forward attack recovery. This commit also simplifies the key rotation check by deleting the snapshot metadata if a threshold of new keys cannot verify the old snapshot metadata. Signed-off-by: Marina Moore <mnm678@gmail.com>

view details

push time in 8 days

PullRequestReviewEvent

Pull request review commenttheupdateframework/taps

TAP-X: Remove signature wrapper from TUF spec, and update reference implementation to use DSSE

+* TAP: 17+* Title: Remove Signature Wrapper from the TUF Specification+* Version: 0+* Last-Modified: 22/06/2021+* Author: Aditya Sirish A Yelgundhalli, Marina Moore+* Type: Standardization+* Status: Draft+* Content-Type: markdown+* Created: 30/04/2021+* +TUF-Version:+* +Post-History:++# Abstract++This TUF Augmentation Proposal (TAP) proposes removing the definition of a+specific signature wrapper and key definitions, and instead defines certain+properties a wrapper must have. Further, it suggests POUF-1 as an example+implementors can refer to when choosing to generate TUF metadata.++# Specification++The TUF specification currently, as of June 2021, uses a custom signature+wrapper. At the time of authoring this document, the primary reference+implementation written in Python also generates TUF metadata using the same+signature wrapper.++However, TUF does not mandate the use of this signature wrapper, nor any+specific metaformat. Indeed, TAP-11, "Using POUFs for Interoperability" enables+adopters to make their own decisions for their implementations, and provides a+mechanism for them to document their decisions. POUF-1 is the POUF for the+official reference implementation, and it seems like the obvious choice for this+information to be specified.++Section 4.2 of the TUF specification, titled "File formats: general principles"+may be replaced by a description of the properties that any signature wrapper used+by a TUF implementation must provide. Some important properties:++* SHOULD include an authenticated payload type+* SHOULD avoid depending on canonicalization for security+* SHOULD NOT require the verifier to parse the payload before verifying+* SHOULD NOT require the inclusion of signing key algorithms in the signature+* MUST support the inclusion of multiple signatures in a file+* SHOULD support a hint indicating what signing key was used, i.e., a KEYID++The presence of an authenticated payload type can be valuable for a project like TUF,+with multiple implementations and derivatives. Indeed, every POUF that describes an+implementation MUST choose a unique payload type, ensuring that there is no confusion+about which implementation generated some piece of metadata.++# Motivation++TAP-11 introduced the concept of POUFs but the TUF specification continues to+specify example formats, namely those used by the reference implementation as+of June 2021. These definitions are essentially replicated in POUF-1, which is+meant to be the authoritative source for information about the reference+implementation. By replacing these definitions with *properties* that a wrapper+must possess, the specification can aid adopters with the development of their+implementations and the POUF can serve as an example. In this scenario, both+documents are serving the purpose originally envisioned for them.++Further, the examples used in the specification are from the old signature+wrapper that includes certain side effects:+* it requires canonicalization before signature verification+* it does not allow for distinguishing different implementations that may have slightly different formats, i.e., it's missing a payload type++# Rationale++Moving the signature wrapper details out of the specification, and instead+requiring adopters to refer to POUFs for examples ensures a clean separation+between implementation details and the TUF specification. Indeed, it also+ensures that the focus of the reader is on only the TUF primitives rather+than burdening them with the specifics of the signature wrapper.++# Security Analysis++Any implementations that build on the properties listed in this document+will have their security enhanced.++# Backwards Compatibility++No backwards incompatibility.

@erickt I wrote a TAP about managing TUF versions that describes a version of publishing metadata using multiple formats that you might be interested in. I'm hoping we can get that or something similar working before adding this and other breaking changes to the spec.

adityasaky

comment created time in 8 days

PullRequestReviewEvent
PullRequestReviewEvent