profile
viewpoint
Trishank Karthik Kuppusamy trishankatdatadog @DataDog New York, NY https://keybase.io/trishankdatadog Staff Security Engineer at @DataDog. Helped to research and develop @theupdateframework and @uptane.

DataDog/integrations-core 344

Core integrations of the Datadog Agent

DataDog/yubikey 336

YubiKey at Datadog

uptane/uptane-standard 18

standard for Uptane

cnabio/signy 11

Go implementation for CNAB content trust verification using TUF, Notary, and in-toto

engineerd/pysigny 1

[WIP] Python reference implementation for the CNAB security specification, with TUF, and in-toto

DataDog/pip 0

The Python Package Installer (recommended by PyPA)

JustinCappos/toc 0

Technical Oversight Committee (TOC)

secure-systems-lab/peps 0

Python Enhancement Proposals

trishankatdatadog/aws-vault 0

A vault for securely storing and accessing AWS credentials in development environments

trishankatdatadog/cnab-spec 0

Cloud Native Application Bundle Specification

push eventcnabio/signy

Radu M

commit sha 3cd3dbec94ef3cfdcf8868b1a79e7409ca8ceb6a

Rename import package to reflect future organization change to cnabio Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha e243fd5f37ae2c750364a6e3c4f1b42e7089490c

Udate package import path for modules and skip setting GOPATH in CI Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 3bd0d0e41693b75bf423153663b3f971da03a768

Update Makefile and remove dep Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 21e031d2a8679af54b426d1d81070eb381e25cfc

Merge pull request #42 from radu-matei/move-cnabio Rename import package to reflect future org change to `cnabio`

view details

Jacob LeGrone

commit sha 5e924eaca48139f0baf2de97cf5c17f72fc50663

Add godoc badge Signed-off-by: Jacob LeGrone <git@jacob.work>

view details

Trishank Karthik Kuppusamy

commit sha ff3acfb778bec2912f16c2f1a54cb4adb9e79cf7

Merge pull request #57 from jlegrone/patch-1 Add godoc badge

view details

Trishank Karthik Kuppusamy

commit sha d20129623cca08c03ff394411850374c6740db05

Merge branch 'master' into trishankatdatadog/cmd-to-make-keys

view details

push time in 3 days

PR opened cnabio/signy

Reviewers
Improve default key management experience
  1. Push snapshot key, just like timestamp, to Notary server.
  2. Reuse targets key, just like root, across bundle repositories.
  3. Delegate all bundles from targets totargets/releases` for better security posture.
+108 -38

0 comment

10 changed files

pr created time in 3 days

push eventcnabio/signy

Jacob LeGrone

commit sha 5e924eaca48139f0baf2de97cf5c17f72fc50663

Add godoc badge Signed-off-by: Jacob LeGrone <git@jacob.work>

view details

Trishank Karthik Kuppusamy

commit sha ff3acfb778bec2912f16c2f1a54cb4adb9e79cf7

Merge pull request #57 from jlegrone/patch-1 Add godoc badge

view details

push time in 3 days

PR merged cnabio/signy

Add godoc badge

This helps grok what signy provides. 😄

+2 -0

0 comment

1 changed file

jlegrone

pr closed time in 3 days

push eventDataDog/yubikey

Trishank Karthik Kuppusamy

commit sha f1d0e406351aaa02371007bdd92d064d25134b11

rsa 4096-> 3072 (lowest common denominator)

view details

Trishank Karthik Kuppusamy

commit sha 59a09079ab6701df2a2c8d23607fbef52761ff06

do not replace gpg-agent.conf when setting up ssh reload shell config when setting up ssh ignore ssh *.pub keys

view details

push time in 3 days

pull request commentcnabio/cnab-spec

CNAB Security 304: Known implementations

@technosophos Ooops, got it, thanks!

radu-matei

comment created time in 3 days

pull request commentcnabio/cnab-spec

CNAB Security 304: Known implementations

@technosophos As a 1.0 WD, it is fine. We are working on the Go implementation right now, so things will change in the near future :)

radu-matei

comment created time in 3 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha e0a06b3df46684e74629f8be3fdea26a95655e42

fixes for fascist golangci-lint Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 4 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha 0de5b09fc0747d5b08e261073ea1164e8036004e

reuse a single targets key across repos Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 4 days

issue commentcnabio/cnab-spec

Declarative installation support

In fact, we can go beyond only trusting only our deployment tool, and verify the whole bundle. The security spec is an attempt to formalize this, and I think any deficiencies in this model should be addressed there.

I agree: CNAB-Sec should be able to give guarantees on the authenticity, integrity, and even provenance of your bundle. If something is missing, please let us know.

glyn

comment created time in 5 days

create barnchengineerd/signy

branch : trishankatdatadog/cmd-to-make-keys

created branch time in 5 days

startedPawelPleskaczynski/go-pt

started time in 5 days

Pull request review commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

 non-volatile storage as FILENAME.EXT.     metadata file, discard it, abort the update cycle, and report the potential     rollback attack. -    * **3.3.3**. The version number of the targets metadata file, and all-    delegated targets metadata files (if any), in the trusted snapshot metadata-    file, if any, MUST be less than or equal to its version number in the new-    snapshot metadata file. Furthermore, any targets metadata filename that was-    listed in the trusted snapshot metadata file, if any, MUST continue to be-    listed in the new snapshot metadata file.  If any of these conditions are-    not met, discard the new snaphot metadadata file, abort the update cycle,-    and report the failure.+    * **3.3.3**. The version number of the top-level targets metadata file, in+    the trusted snapshot metadata file, if any, MUST be less than or equal to+    its version number in the new snapshot metadata file. Furthermore, any+    targets metadata filename that was listed in the trusted snapshot metadata+    file, if any, MUST continue to be listed in the new snapshot metadata file.

Yes, I think we need a meeting.

lukpueh

comment created time in 5 days

pull request commenttheupdateframework/specification

Clarify timestamp.json METAFILES format

@lukpueh Yeah, I think we should make a determination whether we're going to use them or not. Let's discuss in the next community meeting.

P.S. At the time that part of the spec was written, I don't think the Mercury paper was around.

joshuagl

comment created time in 5 days

issue commentpypa/warehouse

Roadmap update for TUF support

Also TL would be a nice upgrade to the --generate-hashes/--require-hashes workflow as you'd only need to record the latest TL root. And no need for any public key cryptography

Yes, at the risk of adding new, malicious versions of packages when the TL is compromised.

LucidOne

comment created time in 6 days

issue openedengineerd/signy

Split GUN and target filename correctly

For example, port numbers (e.g., localhost:5000/helloworld-bundle:v1) can throw off Signy:

{
  "signed": {
    "_type": "Targets",
    "delegations": {
      "keys": {},
      "roles": []
    },
    "expires": "2023-02-10T18:17:02.946024-05:00",
    "targets": {
      "5000/helloworld-bundle": {
        "hashes": {
          "sha256": "x+kr1R8FnWCxWtRW7fGUZImX1zn2B5mzfgjtr9iKgbU=",
          "sha512": "VgQ/Bcy/5IGpguFN65K5hUPM324iFO3jyDLEfFO5RcVzdSilkHhDIJemRxADrWDSX2AVM8qrjTqZg7BRbxt61g=="
        },
        "length": 501
      },
      "5000/thin-bundle": {
        "hashes": {
          "sha256": "x+kr1R8FnWCxWtRW7fGUZImX1zn2B5mzfgjtr9iKgbU=",
          "sha512": "VgQ/Bcy/5IGpguFN65K5hUPM324iFO3jyDLEfFO5RcVzdSilkHhDIJemRxADrWDSX2AVM8qrjTqZg7BRbxt61g=="
        },
        "length": 501
      }
    },
    "version": 3
  },
  "signatures": [
    {
      "keyid": "8862fb206c8bf700caa44620b76f52084d1c0494565abef9c27517546d55105e",
      "method": "ecdsa",
      "sig": "z+4XjB6gLaU2ozfyb9cjg/xWhMaiN3Wety40UHiwJTZjHwufUK5hALBVW5ZSzJI2iRSA5WIpAblKarXPl0LkLA=="
    }
  ]
}

created time in 6 days

issue commentpypa/warehouse

Roadmap update for TUF support

If everything was being signed with offline keys, then I also don't think a TL would add much.

However that isn't the situation that we expect to end up in, even if PEP 480 has been accepted and implemented. Instead, we expect the vast majority of packages to be signed by PyPI (with historical metadata protection provided via a TL), and a subset of publishers opting in to managing their own signing keys and gaining the full metadata protection offered by TUF.

Right. I should note that only a few publishers (e.g., top 20% packages) need to opt-in to get a lot of bang for the buck (e.g., 80% of downloads). That said, adding a TL to record history wouldn't hurt.

LucidOne

comment created time in 6 days

startedgoogle/trillian

started time in 6 days

Pull request review commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

 non-volatile storage as FILENAME.EXT.     metadata file, discard it, abort the update cycle, and report the potential     rollback attack. -    * **3.3.3**. The version number of the targets metadata file, and all-    delegated targets metadata files (if any), in the trusted snapshot metadata-    file, if any, MUST be less than or equal to its version number in the new-    snapshot metadata file. Furthermore, any targets metadata filename that was-    listed in the trusted snapshot metadata file, if any, MUST continue to be-    listed in the new snapshot metadata file.  If any of these conditions are-    not met, discard the new snaphot metadadata file, abort the update cycle,-    and report the failure.+    * **3.3.3**. The version number of the top-level targets metadata file, in+    the trusted snapshot metadata file, if any, MUST be less than or equal to+    its version number in the new snapshot metadata file. Furthermore, any+    targets metadata filename that was listed in the trusted snapshot metadata+    file, if any, MUST continue to be listed in the new snapshot metadata file.

I see. Hmm, this requires careful thinking and modeling. I want to make sure we cover all of our bases. Right now, it doesn't look like it, but maybe I'm wrong.

lukpueh

comment created time in 6 days

Pull request review commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

 non-volatile storage as FILENAME.EXT.     metadata file, discard it, abort the update cycle, and report the potential     rollback attack. -    * **3.3.3**. The version number of the targets metadata file, and all-    delegated targets metadata files (if any), in the trusted snapshot metadata-    file, if any, MUST be less than or equal to its version number in the new-    snapshot metadata file. Furthermore, any targets metadata filename that was-    listed in the trusted snapshot metadata file, if any, MUST continue to be-    listed in the new snapshot metadata file.  If any of these conditions are-    not met, discard the new snaphot metadadata file, abort the update cycle,-    and report the failure.+    * **3.3.3**. The version number of the top-level targets metadata file, in+    the trusted snapshot metadata file, if any, MUST be less than or equal to+    its version number in the new snapshot metadata file. Furthermore, any+    targets metadata filename that was listed in the trusted snapshot metadata+    file, if any, MUST continue to be listed in the new snapshot metadata file.

All targets files. Isn't this the Mercury workflow for snapshot?

lukpueh

comment created time in 6 days

Pull request review commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

 non-volatile storage as FILENAME.EXT.     metadata file, discard it, abort the update cycle, and report the potential     rollback attack. -    * **3.3.3**. The version number of the targets metadata file, and all-    delegated targets metadata files (if any), in the trusted snapshot metadata-    file, if any, MUST be less than or equal to its version number in the new-    snapshot metadata file. Furthermore, any targets metadata filename that was-    listed in the trusted snapshot metadata file, if any, MUST continue to be-    listed in the new snapshot metadata file.  If any of these conditions are-    not met, discard the new snaphot metadadata file, abort the update cycle,-    and report the failure.+    * **3.3.3**. The version number of the top-level targets metadata file, in+    the trusted snapshot metadata file, if any, MUST be less than or equal to+    its version number in the new snapshot metadata file. Furthermore, any+    targets metadata filename that was listed in the trusted snapshot metadata+    file, if any, MUST continue to be listed in the new snapshot metadata file.

Hold on, I'm confused.

When you use root to rotate timestamp and snapshot, you discard the previous snapshot metadata file, no? And isn't rotating root the first thing we do? So why can't you check vernum for every targets metadata file?

lukpueh

comment created time in 6 days

Pull request review commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

 non-volatile storage as FILENAME.EXT.     metadata file, discard it, abort the update cycle, and report the potential     rollback attack. -    * **3.3.3**. The version number of the targets metadata file, and all-    delegated targets metadata files (if any), in the trusted snapshot metadata-    file, if any, MUST be less than or equal to its version number in the new-    snapshot metadata file. Furthermore, any targets metadata filename that was-    listed in the trusted snapshot metadata file, if any, MUST continue to be-    listed in the new snapshot metadata file.  If any of these conditions are-    not met, discard the new snaphot metadadata file, abort the update cycle,-    and report the failure.+    * **3.3.3**. The version number of the top-level targets metadata file, in+    the trusted snapshot metadata file, if any, MUST be less than or equal to+    its version number in the new snapshot metadata file. Furthermore, any+    targets metadata filename that was listed in the trusted snapshot metadata+    file, if any, MUST continue to be listed in the new snapshot metadata file.

Doesn't look like it, because Mercury prescribes checking vernum of every targets metadata file.

lukpueh

comment created time in 6 days

Pull request review commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

 non-volatile storage as FILENAME.EXT.     metadata file, discard it, abort the update cycle, and report the potential     rollback attack. -    * **3.3.3**. The version number of the targets metadata file, and all-    delegated targets metadata files (if any), in the trusted snapshot metadata-    file, if any, MUST be less than or equal to its version number in the new-    snapshot metadata file. Furthermore, any targets metadata filename that was-    listed in the trusted snapshot metadata file, if any, MUST continue to be-    listed in the new snapshot metadata file.  If any of these conditions are-    not met, discard the new snaphot metadadata file, abort the update cycle,-    and report the failure.+    * **3.3.3**. The version number of the top-level targets metadata file, in+    the trusted snapshot metadata file, if any, MUST be less than or equal to+    its version number in the new snapshot metadata file. Furthermore, any+    targets metadata filename that was listed in the trusted snapshot metadata+    file, if any, MUST continue to be listed in the new snapshot metadata file.

Hmmm, this basically breaks the workflow described in the Mercury paper, unless we're doing it elsewhere.

lukpueh

comment created time in 6 days

issue commentpypa/warehouse

Roadmap update for TUF support

Thanks for pinging us @JustinCappos

@graingert Right, I agree with Justin: for an open source repository like PyPI, using TUF gives you the guarantee you ultimately want: attackers not being able to tamper with packages signed w/ offline keys. We stress in that blog post that TLs don't give you this property out of the box. We recommending using a TL on top of TUF so that you an audit the TUF metadata, if necessary.

LucidOne

comment created time in 6 days

delete branch engineerd/signy

delete branch : trishankatdatadog/useful-dev-scripts

delete time in 7 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha a6d3ab61d5fdcb1ad1892ddedc937ad2f3d860ac

useful dev scripts Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 8bc90a48a59c80b48faab87ac415e69dd4344940

useful dev scripts Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 29abec51585493c63b1ae0fa4897c8c942f3c244

diff start scripts for Notary and signy Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 78a8c8ef1c0b96404b69b551e26c8c1bf0035c79

update README Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha cfb230c189ae172ce4a25bd530b583580cec9278

more handy scripts Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 565670b72cca9ef418a1d541ccc2feaa500d0755

reset script Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha cd953f454e9bcada16ffb897fb31c872aaa6093a

rename bundle; make note of list not working Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank Karthik Kuppusamy

commit sha 3254a690cd00ef632239a7674aa8c64ef9cf594a

Merge pull request #45 from engineerd/trishankatdatadog/useful-dev-scripts Useful dev scripts

view details

push time in 7 days

PR merged engineerd/signy

Useful dev scripts

For building and development

+152 -47

0 comment

14 changed files

trishankatdatadog

pr closed time in 7 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha cd953f454e9bcada16ffb897fb31c872aaa6093a

rename bundle; make note of list not working Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 7 days

issue openedengineerd/signy

Support multiple path separators in bundle names

localhost:5000/thin-bundle:v1 works, but not localhost:5000/cnab/thin-bundle:v1

created time in 7 days

issue commentengineerd/signy

Timestamp key passphrase not correctly set

I will look into this

radu-matei

comment created time in 7 days

issue commentengineerd/signy

Switch to Go modules

This is closed by #47 , no?

radu-matei

comment created time in 7 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha 565670b72cca9ef418a1d541ccc2feaa500d0755

reset script Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 7 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha cfb230c189ae172ce4a25bd530b583580cec9278

more handy scripts Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 7 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha 78a8c8ef1c0b96404b69b551e26c8c1bf0035c79

update README Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 7 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha 29abec51585493c63b1ae0fa4897c8c942f3c244

diff start scripts for Notary and signy Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 7 days

issue openedcnabio/cnab-to-oci

Pushing a CNAB bundle to localhost TLS Registry fails

Steps to reproduce:

  1. Run scripts/notary-start.sh.
 $ signy --tlscacert=/Users/trishank.kuppusamy/go/src/github.com/theupdateframework/notary/cmd/notary/root-ca.crt --server=https://localhost:4443 --log=debug sign testdata/cnab/bundle.json localhost:5000/cnab/helloworld:0.1.1
DEBU[0000] Fixing up bundle localhost:5000/cnab/helloworld:0.1.1
DEBU[0000] Updating entry in relocation map for "cnab/helloworld:0.1.1"
INFO[0000] Starting to copy image cnab/helloworld:0.1.1
INFO[0000] Failed to copy image cnab/helloworld:0.1.1: failed to do request: Head http://localhost:5000/v2/cnab/helloworld/blobs/sha256:58e6f39290459b6563b348052b2a1a8cf2a44fac19a80ae0da36c82a32f151f8: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
Error: failed to do request: Head http://localhost:5000/v2/cnab/helloworld/blobs/sha256:58e6f39290459b6563b348052b2a1a8cf2a44fac19a80ae0da36c82a32f151f8: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
Usage:
  signy sign [file] [target reference] [flags]

Flags:
  -h, --help                help for sign
      --in-toto             Adds in-toto metadata to TUF. If passed, the root layout, links directory, and root kyes must be supplied
      --layout string       Path to the in-toto root layout file
      --layout-key string   Path to the in-toto root layout public keys
      --links string        Path to the in-toto links directory
      --root-key string     Root key to initialize the repository with
      --thick               Signs a thick bundle. If passed, only the signature is pushed to the trust server, not the bundle file

Global Flags:
  -d, --dir string         Directory where the trust data is persisted to (default "/Users/trishank.kuppusamy/.signy")
      --log string         Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")
      --server string      The trust server used (default "https://notary.docker.io")
  -t, --timeout string     Timeout for the trust server (default "5s")
      --tlscacert string   Trust certs signed only by this CA

failed to do request: Head http://localhost:5000/v2/cnab/helloworld/blobs/sha256:58e6f39290459b6563b348052b2a1a8cf2a44fac19a80ae0da36c82a32f151f8: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
  1. Run scripts/stop.sh.

  2. Run scripts/signy-start.sh.

signy --tlscacert=/Users/trishank.kuppusamy/go/src/github.com/theupdateframework/notary/cmd/notary/root-ca.crt --server=https://localhost:4443 --log=debug sign testdata/cnab/bundle.json localhost:5000/cnab/helloworld:0.1.1
DEBU[0000] Fixing up bundle localhost:5000/cnab/helloworld:0.1.1
DEBU[0000] Updating entry in relocation map for "cnab/helloworld:0.1.1"
INFO[0000] Starting to copy image cnab/helloworld:0.1.1
INFO[0001] Completed image cnab/helloworld:0.1.1 copy
DEBU[0001] Bundle fixed
INFO[0001] Generated relocation map: relocation.ImageRelocationMap{"cnab/helloworld:0.1.1":"localhost:5000/cnab/helloworld@sha256:a59a4e74d9cc89e4e75dfb2cc7ea5c108e4236ba6231b53081a9e2506d1197b6"}
DEBU[0001] Pushing CNAB Bundle localhost:5000/cnab/helloworld:0.1.1
DEBU[0001] Pushing CNAB Bundle Config
DEBU[0001] Trying to push CNAB Bundle Config
DEBU[0001] CNAB Bundle Config Descriptor
DEBU[0001] {
  "mediaType": "application/vnd.cnab.config.v1+json",
  "digest": "sha256:c7e92bd51f059d60b15ad456edf194648997d739f60799b37e08edafd88a81b5",
  "size": 501
}
DEBU[0001] Trying to push CNAB Bundle Config Manifest
DEBU[0001] CNAB Bundle Config Manifest Descriptor
DEBU[0001] {
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "digest": "sha256:c88087935c91817e3421c41794ace533f597428d4a9617bf7a6de5bc4200d8da",
  "size": 188
}
DEBU[0001] CNAB Bundle Config pushed
DEBU[0001] Pushing CNAB Index
DEBU[0001] Trying to push OCI Index
DEBU[0001] {"schemaVersion":2,"manifests":[{"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:c88087935c91817e3421c41794ace533f597428d4a9617bf7a6de5bc4200d8da","size":188,"annotations":{"io.cnab.manifest.type":"config"}},{"mediaType":"application/vnd.docker.distribution.manifest.v2+json","digest":"sha256:a59a4e74d9cc89e4e75dfb2cc7ea5c108e4236ba6231b53081a9e2506d1197b6","size":942,"annotations":{"io.cnab.manifest.type":"invocation"}}],"annotations":{"io.cnab.keywords":"[\"helloworld\",\"cnab\",\"tutorial\"]","io.cnab.runtime_version":"v1.0.0-WD","org.opencontainers.artifactType":"application/vnd.cnab.manifest.v1","org.opencontainers.image.authors":"[{\"name\":\"Jane Doe\",\"email\":\"jane.doe@example.com\",\"url\":\"https://example.com\"}]","org.opencontainers.image.description":"A short description of your bundle","org.opencontainers.image.title":"helloworld","org.opencontainers.image.version":"0.1.1"}}
DEBU[0001] OCI Index Descriptor
DEBU[0001] {
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "digest": "sha256:b4936e42304c184bafc9b06dde9ea1f979129e09a021a8f40abc07f736de9268",
  "size": 929
}
DEBU[0001] CNAB Index pushed
DEBU[0001] CNAB Bundle pushed
INFO[0001] Pushed successfully, with digest "sha256:b4936e42304c184bafc9b06dde9ea1f979129e09a021a8f40abc07f736de9268"
DEBU[0001] cannot get default credentials: authentication not found for trust server https://localhost:4443
DEBU[0001] Making dir path: /Users/trishank.kuppusamy/.signy/tuf/localhost/changelist
DEBU[0001] entered ValidateRoot with dns: localhost
DEBU[0001] found the following root keys: [f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9]
DEBU[0001] found 1 valid leaf certificates for localhost: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] found 1 leaf certs, of which 1 are valid leaf certs for localhost
DEBU[0001] checking root against trust_pinning config for localhost
DEBU[0001] checking trust-pinning for cert: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001]  role has key IDs: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] verifying signature for key ID: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] root validation succeeded for localhost
DEBU[0001] entered ValidateRoot with dns: localhost
DEBU[0001] found the following root keys: [f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9]
DEBU[0001] found 1 valid leaf certificates for localhost: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] found 1 leaf certs, of which 1 are valid leaf certs for localhost
DEBU[0001] checking root against trust_pinning config for localhost
DEBU[0001] checking trust-pinning for cert: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001]  role has key IDs: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] verifying signature for key ID: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] root validation succeeded for localhost
DEBU[0001] updating TUF client
DEBU[0001] Loading timestamp...
DEBU[0001] 200 when retrieving metadata for timestamp
DEBU[0001] timestamp role has key IDs: 919e5d9116881bfdfb2cc8d02f4836b2da7894c6c4bb65a0078333228aff945d
DEBU[0001] verifying signature for key ID: 919e5d9116881bfdfb2cc8d02f4836b2da7894c6c4bb65a0078333228aff945d
DEBU[0001] timestamp role has key IDs: 919e5d9116881bfdfb2cc8d02f4836b2da7894c6c4bb65a0078333228aff945d
DEBU[0001] verifying signature for key ID: 919e5d9116881bfdfb2cc8d02f4836b2da7894c6c4bb65a0078333228aff945d
DEBU[0001] successfully verified downloaded timestamp
DEBU[0001] Loading snapshot...
DEBU[0001] cached snapshot is invalid (must download): sha256 checksum for snapshot did not match: expected bf3b30295e102d65d567c2644980d748ebe8b1c8b1981c46edbabd547ac75512
DEBU[0001] 200 when retrieving metadata for snapshot.bf3b30295e102d65d567c2644980d748ebe8b1c8b1981c46edbabd547ac75512
DEBU[0001] snapshot role has key IDs: 83abf5bc3119245b26d6af7542f87a8c30e625d3cc62078123d517f2ad48fc80
DEBU[0001] verifying signature for key ID: 83abf5bc3119245b26d6af7542f87a8c30e625d3cc62078123d517f2ad48fc80
DEBU[0001] snapshot role has key IDs: 83abf5bc3119245b26d6af7542f87a8c30e625d3cc62078123d517f2ad48fc80
DEBU[0001] verifying signature for key ID: 83abf5bc3119245b26d6af7542f87a8c30e625d3cc62078123d517f2ad48fc80
DEBU[0001] successfully verified downloaded snapshot.bf3b30295e102d65d567c2644980d748ebe8b1c8b1981c46edbabd547ac75512
DEBU[0001] Loading targets...
DEBU[0001] targets role has key IDs: c3bfdf9b15f43aebe73ae2011c3b101176c448a69057e48867a2cfab0ec30c97
DEBU[0001] verifying signature for key ID: c3bfdf9b15f43aebe73ae2011c3b101176c448a69057e48867a2cfab0ec30c97
DEBU[0001] successfully verified cached targets
DEBU[0001] Adding target "5000/cnab/helloworld" with sha256 "c7e92bd51f059d60b15ad456edf194648997d739f60799b37e08edafd88a81b5" and size 501 bytes.
DEBU[0001] entered ValidateRoot with dns: localhost
DEBU[0001] found the following root keys: [f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9]
DEBU[0001] found 1 valid leaf certificates for localhost: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] found 1 leaf certs, of which 1 are valid leaf certs for localhost
DEBU[0001] checking root against trust_pinning config for localhost
DEBU[0001] checking trust-pinning for cert: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001]  role has key IDs: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] verifying signature for key ID: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] root validation succeeded for localhost
DEBU[0001] entered ValidateRoot with dns: localhost
DEBU[0001] found the following root keys: [f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9]
DEBU[0001] found 1 valid leaf certificates for localhost: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] found 1 leaf certs, of which 1 are valid leaf certs for localhost
DEBU[0001] checking root against trust_pinning config for localhost
DEBU[0001] checking trust-pinning for cert: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001]  role has key IDs: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] verifying signature for key ID: f01c4109378763e9908eeed725c691586aa7c1b735c312989f64270f7925a9b9
DEBU[0001] root validation succeeded for localhost
DEBU[0001] 200 when retrieving metadata for root
DEBU[0001] updating TUF client
DEBU[0001] Loading timestamp...
DEBU[0001] 200 when retrieving metadata for timestamp
DEBU[0001] timestamp role has key IDs: 919e5d9116881bfdfb2cc8d02f4836b2da7894c6c4bb65a0078333228aff945d
DEBU[0001] verifying signature for key ID: 919e5d9116881bfdfb2cc8d02f4836b2da7894c6c4bb65a0078333228aff945d
DEBU[0001] timestamp role has key IDs: 919e5d9116881bfdfb2cc8d02f4836b2da7894c6c4bb65a0078333228aff945d
DEBU[0001] verifying signature for key ID: 919e5d9116881bfdfb2cc8d02f4836b2da7894c6c4bb65a0078333228aff945d
DEBU[0001] successfully verified downloaded timestamp
DEBU[0001] Loading snapshot...
DEBU[0001] snapshot role has key IDs: 83abf5bc3119245b26d6af7542f87a8c30e625d3cc62078123d517f2ad48fc80
DEBU[0001] verifying signature for key ID: 83abf5bc3119245b26d6af7542f87a8c30e625d3cc62078123d517f2ad48fc80
DEBU[0001] successfully verified cached snapshot
DEBU[0001] Loading targets...
DEBU[0001] targets role has key IDs: c3bfdf9b15f43aebe73ae2011c3b101176c448a69057e48867a2cfab0ec30c97
DEBU[0001] verifying signature for key ID: c3bfdf9b15f43aebe73ae2011c3b101176c448a69057e48867a2cfab0ec30c97
DEBU[0001] successfully verified cached targets
DEBU[0001] changelist add: 5000/cnab/helloworld
Enter passphrase for targets key with ID c3bfdf9:
DEBU[0005] applied 1 change(s)
DEBU[0005] signing snapshot...
DEBU[0005] sign called with 1/1 required keys
Enter passphrase for snapshot key with ID 83abf5b:
DEBU[0006] sign called with 0/0 required keys
INFO[0006] Pushed trust data for localhost:5000/cnab/helloworld:0.1.1: c7e92bd51f059d60b15ad456edf194648997d739f60799b37e08edafd88a81b5

Most likely has to do with using self-signed TLS cert.

created time in 7 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha efcd3cf93360b92712ea25ae94be3cd3545919cb

diff start scripts for Notary and signy

view details

push time in 7 days

Pull request review commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

 non-volatile storage as FILENAME.EXT.     metadata file, discard it, abort the update cycle, and report the potential     rollback attack. -    * **3.3.3**. The version number of the targets metadata file, and all-    delegated targets metadata files (if any), in the trusted snapshot metadata-    file, if any, MUST be less than or equal to its version number in the new-    snapshot metadata file. Furthermore, any targets metadata filename that was-    listed in the trusted snapshot metadata file, if any, MUST continue to be-    listed in the new snapshot metadata file.  If any of these conditions are-    not met, discard the new snaphot metadadata file, abort the update cycle,-    and report the failure.+    * **3.3.3**. The version number of the top-level targets metadata file, in+    the trusted snapshot metadata file, if any, MUST be less than or equal to+    its version number in the new snapshot metadata file. Furthermore, any+    targets metadata filename that was listed in the trusted snapshot metadata+    file, if any, MUST continue to be listed in the new snapshot metadata file.

Hold on, why are we not checking that every version number for every targets metadata file (including delegations) in the previous snapshot, if any, is <= the current metadata file?

lukpueh

comment created time in 7 days

Pull request review commenttheupdateframework/specification

Clarify rollback attack prevention and fast-forward attack recovery

 non-volatile storage as FILENAME.EXT.   trusted root metadata file.  If the new targets metadata file is not signed   as required, discard it, abort the update cycle, and report the failure. -  * **4.3**. **Check for a freeze attack.** The latest known time should be+  * **4.3**. **Check for a rollback attack.** The version number of the trusted+  targets metadata file, if any, MUST be less than or equal to the version+  number of the new targets metadata file.  If the new targets metadata file is+  older than the trusted targets metadata file, discard it, abort the update+  cycle, and report the potential rollback attack.++  * **4.4**. **Check for a freeze attack.** The latest known time should be   lower than the expiration timestamp in the new targets metadata file.  If so,   the new targets metadata file becomes the trusted targets metadata file.  If   the new targets metadata file is expired, discard it, abort the update cycle,   and report the potential freeze attack. -  * **4.4**. **Perform a preorder depth-first search for metadata about the-  desired target, beginning with the top-level targets role.**  Note: If-  any metadata requested in steps 4.4.1 - 4.4.2.3 cannot be downloaded nor-  validated, end the search and report that the target cannot be found.+  * **4.5**. **Perform a preorder depth-first search for metadata about the+  desired target.** Let TARGETS be the current metadata, beginning with the+  top-level targets metadata role. -    * **4.4.1**. If this role has been visited before, then skip this role (so+    * **4.5.1**. If this role has been visited before, then skip this role (so     that cycles in the delegation graph are avoided).  Otherwise, if an     application-specific maximum number of roles have been visited, then go to     step 5 (so that attackers cannot cause the client to waste excessive     bandwidth or time).  Otherwise, if this role contains metadata about the     desired target, then go to step 5. -    * **4.4.2**. Otherwise, recursively search the list of delegations in order+    * **4.5.2**. Otherwise, recursively search the list of delegations in order     of appearance. -      * **4.4.2.1**. If the current delegation is a multi-role delegation,+      * **4.5.2.1**. Let DELEGATE denote the current target role TARGETS is

Could we please say DELEGATEE instead of DELEGATE? Maybe ask @jhdalek55?

lukpueh

comment created time in 7 days

pull request commenttheupdateframework/specification

Clarify timestamp.json METAFILES format

My off-the-cuff thoughts are: having a version number is good, having a length is good, having a hash is good, and having all three seems to be the best. I believe it may be possible to drop one or more (but we would want to think very carefully about this), but is there a reason not to list all three?

Yeah, but shouldn't the snapshot also list all three by that logic? Don't we accept some tradeoff in security for b/w performance there? Here there is no such demand, but I find all the scenarios above fairly contrived. Having said that, there's absolutely no reason to drop all 3 in timestamp except for some aesthetic consistency.

joshuagl

comment created time in 7 days

pull request commentcnabio/cnab-to-oci

Complete minimal bundle.json that needs no fixup

Sure! Do you mean the README? Where specifically do you think would be best?

trishankatdatadog

comment created time in 10 days

create barnchtrishankatdatadog/ssl-site

branch : trishankatdatadog/minor-fixes

created branch time in 10 days

push eventtrishankatdatadog/cnab-to-oci

Trishank K Kuppusamy

commit sha 138efa49ed2cda42a353b4180201b207742707e5

separate fixup and complete bundles Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 10 days

pull request commentcnabio/cnab-to-oci

Complete minimal bundle.json that needs no fixup

Hmm, looks like that bundle is deliberately designed to need a fixup! Will add a separate file.

trishankatdatadog

comment created time in 10 days

push eventtrishankatdatadog/cnab-to-oci

Trishank K Kuppusamy

commit sha e545bd7c8895ca5ca29d9895c92fa314f113dbae

complete minimal bundle.json that needs no fixup Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 10 days

fork trishankatdatadog/cnab-to-oci

Tool to convert CNAB bundle.json to OCI index

fork in 10 days

create barnchtrishankatdatadog/ssl-site

branch : trishankatdatadog/fix-order

created branch time in 10 days

pull request commentsecure-systems-lab/ssl-site

Transparent logs: clarify compromise recovery

@mnm678 Done, thanks! Would you please ✅ and merge? Thanks!

trishankatdatadog

comment created time in 10 days

push eventtrishankatdatadog/ssl-site

Trishank K Kuppusamy

commit sha 1b1b179daeec823241bf4ee288e4f3df6166fdd5

clarify

view details

Trishank K Kuppusamy

commit sha a6ba2aed6ddcab684eb29c321d718969322e48db

make it a footnote to avoid digression

view details

Trishank K Kuppusamy

commit sha 392a715e11ae8594cf2669c442fac1a924b97395

make it a footnote

view details

Trishank K Kuppusamy

commit sha 75e49fab78e293e4425891a9772688e4ea5d2e32

add link to issue

view details

Trishank K Kuppusamy

commit sha c4e745e487e434e6d2bb0fd165e7d0191f69fa7e

add where trust is being removed from

view details

Justin Cappos

commit sha f3e7945c0439d09e6fd6c98adbd4792a5695d723

Merge pull request #98 from trishankatdatadog/trishankatdatadog/transparent-logs-clarify-trust Transparent logs & TUF: clarify trust

view details

Trishank K Kuppusamy

commit sha f51876a11ce6c1d1f1c503701882ad66f91c39fd

Merge remote-tracking branch 'upstream/master'

view details

Trishank K Kuppusamy

commit sha 0c565be0f72fcf09059c4ef0c1c17a6dc985d57b

clarify subtle diff in compromise recovery

view details

push time in 10 days

push eventtrishankatdatadog/ssl-site

Trishank K Kuppusamy

commit sha c4e745e487e434e6d2bb0fd165e7d0191f69fa7e

add where trust is being removed from

view details

push time in 10 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha 2889e44ce1e6700ab4313c36363e7cd4d978ef65

registry-then-notary instead of other way around Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Radu M

commit sha 7d8fd32d3ab42fbc6f430dad04484ab034572f0d

Merge pull request #46 from engineerd/trishankatdatadog/registry-then-notary Push to registry-then-notary instead of other way around

view details

Radu M

commit sha 42ea9afae745fd5c1945178dde9cf732acda0b63

Remove vendor/ directory Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 0799095e6cc45266f4d3b0b249a58f4a2c3501a8

Add support for Go modules Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 6c35d9ce37c69f4be26be44f4f6136f453efa58b

Remove bootstrap target from CI Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 1dd398f7f373d994a0b9a3272afe73b37f84b5a5

Trigger CI with support for go modules Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha bbb8ce8d66b06547826f3b56ef0f62d22123a57b

Update bootstrap target Signed-off-by: Radu M <root@radu.sh>

view details

Trishank Karthik Kuppusamy

commit sha b6590d838447526e24b1eeff0af89dfe78dbac2a

Merge pull request #47 from radu-matei/mods Add Go modules

view details

Trishank K Kuppusamy

commit sha a6d3ab61d5fdcb1ad1892ddedc937ad2f3d860ac

useful dev scripts Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 8bc90a48a59c80b48faab87ac415e69dd4344940

useful dev scripts Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 10 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha 1eda162acdb05a5fce0cbde919feb36ab9b6efac

allow no authentication for notary server Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Radu M

commit sha a8599997c511ba7cfdc4a6557d9567d5e69b4ca5

Merge pull request #44 from engineerd/trishankatdatadog/allow-no-auth allow no authentication for notary server

view details

Trishank K Kuppusamy

commit sha 08b07a97ae9ee39213e6f9fc51613a695d4b9e44

useful dev scripts Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 33f7db25b3f1fac5dcefb250ca7c00a869e9fda2

useful dev scripts Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 10 days

pull request commenttheupdateframework/specification

Clarify timestamp.json METAFILES format

I think we might as well make timestamp consistent with snapshot, so if the latter lists only version numbers, then that's what the former should do, too. I can't imagine we lose much security this way, especially since, in practice, timestamp and snapshot share the same online key anyway, and as long as we set an upper bound on the size of any metadata downloaded. So, length and hashes may go back to being optional, just like in snapshot.

joshuagl

comment created time in 10 days

PR closed engineerd/signy

Support go modules #40

Fixes: #40

I supported go modules.

+75 -739131

3 comments

2260 changed files

u5surf

pr closed time in 10 days

pull request commentengineerd/signy

Support go modules #40

Deprecated by #47, but thanks for your PR, @u5surf!

u5surf

comment created time in 10 days

push eventengineerd/signy

Radu M

commit sha 42ea9afae745fd5c1945178dde9cf732acda0b63

Remove vendor/ directory Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 0799095e6cc45266f4d3b0b249a58f4a2c3501a8

Add support for Go modules Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 6c35d9ce37c69f4be26be44f4f6136f453efa58b

Remove bootstrap target from CI Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha 1dd398f7f373d994a0b9a3272afe73b37f84b5a5

Trigger CI with support for go modules Signed-off-by: Radu M <root@radu.sh>

view details

Radu M

commit sha bbb8ce8d66b06547826f3b56ef0f62d22123a57b

Update bootstrap target Signed-off-by: Radu M <root@radu.sh>

view details

Trishank Karthik Kuppusamy

commit sha b6590d838447526e24b1eeff0af89dfe78dbac2a

Merge pull request #47 from radu-matei/mods Add Go modules

view details

push time in 10 days

PR merged engineerd/signy

Add Go modules

This PR adds support for Go modules. While it removes the vendor/ directory from the tree, it doesn't remove the dep files just yet.

+574 -738278

2 comments

2260 changed files

radu-matei

pr closed time in 10 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha 2889e44ce1e6700ab4313c36363e7cd4d978ef65

registry-then-notary instead of other way around Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 11 days

PR opened engineerd/signy

Reviewers
Push to registry-then-notary instead of other way around

We first push to the Registry, and then Notary. This is so that if we modify the bundle locally, we will not invalidate its signature by first pushing to Notary, and then the Registry.

+11 -6

0 comment

1 changed file

pr created time in 11 days

create barnchengineerd/signy

branch : trishankatdatadog/registry-then-notary

created branch time in 11 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha 9476c49f9785ba032659d63874bacd5030042f21

respect GOPATH

view details

push time in 11 days

PR opened engineerd/signy

Reviewers
Useful dev scripts

For building and development

+88 -21

0 comment

8 changed files

pr created time in 11 days

create barnchengineerd/signy

branch : trishankatdatadog/useful-dev-scripts

created branch time in 11 days

pull request commentsecure-systems-lab/ssl-site

Transparent logs & TUF: clarify trust

Let's wait for Filippo until tomorrow :)

trishankatdatadog

comment created time in 11 days

push eventtrishankatdatadog/ssl-site

Trishank K Kuppusamy

commit sha 75e49fab78e293e4425891a9772688e4ea5d2e32

add link to issue

view details

push time in 11 days

PR opened secure-systems-lab/ssl-site

Transparent logs: clarify compromise recovery

Fix #95

@filosotte and @JustinCappos, would you both please review?

+13 -7

0 comment

2 changed files

pr created time in 11 days

pull request commenttheupdateframework/taps

Added TAP for TUF Version Management

Hi, this was opened at the end of 2018. Is there any plan to move it to Draft anytime soon? :)

mnm678

comment created time in 11 days

pull request commentsecure-systems-lab/securesystemslib

External Signing using CCID/PIV interface.

I am testing it using softhsm to emulate security tokens!

Very nice! Sorry, I haven't closely, but is it part of the test suite?

tanishqjasoria

comment created time in 11 days

push eventtrishankatdatadog/ssl-site

Trishank K Kuppusamy

commit sha a6ba2aed6ddcab684eb29c321d718969322e48db

make it a footnote to avoid digression

view details

Trishank K Kuppusamy

commit sha 392a715e11ae8594cf2669c442fac1a924b97395

make it a footnote

view details

push time in 11 days

pull request commenttheupdateframework/tuf

Revise requirements files and remove pyup

Thanks for your hard work, @lukpueh!

So many requirements files 😅 Are they really necessary? Also, is there an automated to update all of them at once?

lukpueh

comment created time in 11 days

pull request commentsecure-systems-lab/securesystemslib

External Signing using CCID/PIV interface.

Also, how do we test that this works? Docker has tests that somehow tests Yubikeys, not sure how they do it, maybe using emulators.

tanishqjasoria

comment created time in 11 days

push eventtrishankatdatadog/ssl-site

Trishank K Kuppusamy

commit sha 37298d2cc6c1c607dca7859c36396c0a8dce4ad9

smaller headers

view details

Lois Anne DeLong

commit sha 9091b97a3cdab1baa95ed61bd5a39f3d7e0f0c9c

Merge pull request #97 from trishankatdatadog/trishankatdatadog/transparent-logs-fix-headers Transparent logs & TUF: fix headers

view details

Trishank K Kuppusamy

commit sha 08377e7eb697ca5a49e0bae52b157d63c56e4c97

Merge remote-tracking branch 'upstream/master'

view details

Trishank K Kuppusamy

commit sha 85d87e1db42313a450eb0e27ce4bcb333711fd62

minor fixes

view details

Lois Anne DeLong

commit sha f80be4c9597b441e1b4d1fe84a85c3f80fadcb1e

Merge pull request #99 from trishankatdatadog/trishankatdatadog/transparent-logs-fix-figures Transparent logs & TUF: minor fixes

view details

Trishank K Kuppusamy

commit sha d0fc68d82d535122d6a0c35f57210b7ebfab446e

Merge remote-tracking branch 'upstream/master'

view details

push time in 11 days

pull request commenttheupdateframework/tuf

Revise requirements files and remove pyup

@lukpueh Is this PR done or WIP? :)

lukpueh

comment created time in 11 days

pull request commentengineerd/signy

allow no authentication for notary server

Done :)

trishankatdatadog

comment created time in 12 days

push eventengineerd/signy

Trishank K Kuppusamy

commit sha 1eda162acdb05a5fce0cbde919feb36ab9b6efac

allow no authentication for notary server Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 12 days

PR opened engineerd/signy

Reviewers
allow no authentication for notary server
+5 -5

0 comment

1 changed file

pr created time in 12 days

create barnchengineerd/signy

branch : trishankatdatadog/allow-no-auth

created branch time in 12 days

pull request commentcnabio/cnab-spec

CNAB Security 300

Could @vdice or @chris-crone please 👀, ✅, and merge? Thanks!

trishankatdatadog

comment created time in 12 days

push eventtrishankatdatadog/cnab-spec

Carolyn Van Slyck

commit sha b6c701fbe088aab5ca130d716137d50e86b3ec22

Add timestamps to credential set spec Since credential sets could be stored in different locations, not just the file system, having timestamps inside the credential set helps users remember when they last worked with the item. Currently tools such as duffle or porter have to rely on the file timestamps which isn't feasible once we start storing the credential sets in databases, etc. See corresponding PR in cnab-go https://github.com/cnabio/cnab-go/pull/173 Signed-off-by: Carolyn Van Slyck <carolyn.vanslyck@microsoft.com>

view details

Trishank K Kuppusamy

commit sha 56ae29ba2462ed13403e8cc4cd2b30e8d9591271

WIP on 301: metadata repositories Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 432c1694920988357ea3832a30d25e883bc2df46

some WIP Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 1d041a680880095898db0093e8d30b1e3fdc04e6

nearly done with first draft Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 3aad9f51235e7bc0a97858b54d57cfe488c9f9b0

add (new|claimed)-bundles example metadata Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 02975410b27b538bd677d13a122af53643b49e16

correctly backtrack vs terminate delegations Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 20a75a78eb07898ca5e99fc2da2e44ad2019d2ff

update picture Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 14b5a7cfc640755e919b0431599431198797e86c

ignore VSC files Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha b5fb6afbf326683aa8ea721c5d4de74dd23450e0

no spaces between / Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha bd623644ea244f15780901951feed630ff80ebfc

massively simplify stuff Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 8d4ae9a25eae4c394a8ab4f40c7b546dbb253fcf

metadata repos physically distinct or not from cnab registry Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha c354823adc0b7efc1a9b57db2b0ee2b7b10c7099

revamp concepts in the introduction Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 8acedc5bb0a0999b783599820132594d78c37844

write text for MVP Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 2b9c9b98dc49335d066e1e843dced708d591b356

finish security analysis Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 5596fbf3bc2de122567f9f5d12b0af69a1f8ac3d

add newline Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 73cf251c06870c381c85907121340974d4237148

clarify that MVP is optimized for DCT/Notary 0.6.1 also clarify where online and offline keys are kept for MVP Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 339fa9c4a76a427b3aa596c431e51f22d68a48f0

remove unnecessary term "project" Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha 7bd1fef906207ad5af5cfae75c3dd48f52904650

add a note about different servers Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha b4fe4509ef408b1b6e3ccf4f8ad412f476e740ce

address @vdice feedback Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

Trishank K Kuppusamy

commit sha c9b00fcc8cae660970f30df5047f2dbff995b26a

address @technosophos feedback Signed-off-by: Trishank K Kuppusamy <trishank.kuppusamy@datadoghq.com>

view details

push time in 12 days

delete branch trishankatdatadog/ssl-site

delete branch : trishankatdatadog/transparent-logs-fix-figures

delete time in 12 days

PR opened secure-systems-lab/ssl-site

Transparent logs & TUF: minor fixes

Fix a figure, and add a sentence.

+1 -1

0 comment

2 changed files

pr created time in 12 days

pull request commentsecure-systems-lab/ssl-site

Transparent logs & TUF: clarify trust

@FiloSottile Does this look good?

A major design goal for Google was to make sure that the community would not have to trust them blindly, and thus these mechanisms are a means to an end, which is removing trust.

trishankatdatadog

comment created time in 12 days

push eventtrishankatdatadog/ssl-site

Trishank K Kuppusamy

commit sha 967c7a1d6190aef17b7f05959bff250202b15ba5

initial commit

view details

Lois Anne DeLong

commit sha 4d591f9bd3e34a33cc9b39a042a4ad1be4770792

Merge pull request #93 from trishankatdatadog/trishankatdatadog/transparent-logs Contrasting Transparent Logs and TUF

view details

Trishank K Kuppusamy

commit sha 10f471e22bffaa694d6ef9aa359eff8a18678230

fix first two figures

view details

Justin Cappos

commit sha a577219f885bc02ae3cada508db6919b3234b47b

Merge pull request #94 from trishankatdatadog/trishankatdatadog/transparent-logs Transparent logs: fix first two figures

view details

Trishank K Kuppusamy

commit sha 7fa25482e9c93e095ed96b77e1d7a3ee199462a1

Merge remote-tracking branch 'upstream/master'

view details

push time in 12 days

Pull request review commenttheupdateframework/specification

Clarify timestamp.json METAFILES format

 repo](https://github.com/theupdateframework/specification/issues).          "meta" : METAFILES        } -   METAFILES is the same is described for the snapshot.json file.  In the case-   of the timestamp.json file, this MUST only include a description of the-   snapshot.json file.+   METAFILES is an object whose format is the following:++       { METAPATH : {+             "version" : VERSION,+             ("length" : LENGTH, |+              "hashes" : HASHES) }+         , ...+       }++   METAPATH is the snapshot.json file's path on the repository relative to the+   metadata base URL.++   VERSION is the version the snapshot target as listed in the snapshot.json+   file.++   LENGTH is the integer length in bytes of the metadata file.++   HASHES is the dictionary that specifies one or more hashes, including
   HASHES is the dictionary that specifies one or more hashes of the snapshot metadata file, including
joshuagl

comment created time in 12 days

Pull request review commenttheupdateframework/specification

Clarify timestamp.json METAFILES format

 repo](https://github.com/theupdateframework/specification/issues).          "meta" : METAFILES        } -   METAFILES is the same is described for the snapshot.json file.  In the case-   of the timestamp.json file, this MUST only include a description of the-   snapshot.json file.+   METAFILES is an object whose format is the following:++       { METAPATH : {+             "version" : VERSION,+             ("length" : LENGTH, |+              "hashes" : HASHES) }+         , ...+       }++   METAPATH is the snapshot.json file's path on the repository relative to the+   metadata base URL.++   VERSION is the version the snapshot target as listed in the snapshot.json+   file.++   LENGTH is the integer length in bytes of the metadata file.
   LENGTH is the integer length in bytes of the snapshot metadata file.
joshuagl

comment created time in 12 days

Pull request review commenttheupdateframework/specification

Clarify timestamp.json METAFILES format

 repo](https://github.com/theupdateframework/specification/issues).          "meta" : METAFILES        } -   METAFILES is the same is described for the snapshot.json file.  In the case-   of the timestamp.json file, this MUST only include a description of the-   snapshot.json file.+   METAFILES is an object whose format is the following:++       { METAPATH : {+             "version" : VERSION,+             ("length" : LENGTH, |+              "hashes" : HASHES) }
              "hashes" : HASHES }
joshuagl

comment created time in 12 days

Pull request review commenttheupdateframework/specification

Clarify timestamp.json METAFILES format

 repo](https://github.com/theupdateframework/specification/issues).          "meta" : METAFILES        } -   METAFILES is the same is described for the snapshot.json file.  In the case-   of the timestamp.json file, this MUST only include a description of the-   snapshot.json file.+   METAFILES is an object whose format is the following:++       { METAPATH : {+             "version" : VERSION,+             ("length" : LENGTH, |
             "length" : LENGTH, |
joshuagl

comment created time in 12 days

issue commentkubernetes/release

Signing releases with GPG keys

Hi everyone,

Out of curiosity, how are k8s release artifacts signed now?

Also, an open-source alternative is The Update Framework (TUF) and in-toto, which are other CNCF projects. I'm involved in both, and am happy to discuss how to integrate them with k8s. The Datadog Agent integrations uses both to make sure that attacks anywhere between developers and end-users can be detected.

Cc @SantiagoTorres

dims

comment created time in 12 days

issue commentsecure-systems-lab/ssl-site

Transparent Logs and TUF: clarify compromise recovery

I think I'm still missing the semantic difference (that is, beyond where and how the keys are stored). The online keys in TUF are the tree signing keys in the sumdb, the root keys in TUF are the release signing keys in Go, all keys rotate permanently upon update (the signatures by the old untrusted key would be just ignored by updated clients), and if you have a TLS connection to an entity you trust you can pull it off securely.

I think one difference is that in sumdb, you need to update the client to permanently switch root keys, whereas in TUF (PEP 458, for apples-to-apples comparison), you don't need to update the client at all. I'll have to think if other differences exist.

trishankatdatadog

comment created time in 12 days

issue commentsecure-systems-lab/ssl-site

Transparent Logs and TUF: clarify compromise recovery

Yes, that's the plan. Older clients would be vulnerable, but that's just akin to any other security vulnerability in the Go client, which users are expected to apply the patches for.

Thanks for the clarification! TBF, that will also be the case for TUF if a threshold of the root keys themselves are compromised. (However, the bar is expected to be very high here, as the expectation is that you use multiple, offline root keys, possibly even using different signing algorithms.) The difference is that TUF will switch users from the old to the new root keys permanently (which can be done safely provided that attackers no longer control the repository, and the repository is also using TLS).

(FWIW, we don't expect key compromise to be likely at all, as we are relying on the most secure infrastructure that was available to us within Google. But I understand that only works for us, so is pretty irrelevant.)

Yes, I think that's probably one of the biggest differences in assumptions between both systems.

Let me try sending out a PR tomorrow that everyone here can vet...

trishankatdatadog

comment created time in 13 days

issue commentsecure-systems-lab/ssl-site

Transparent Logs and TUF: clarify compromise recovery

Almost, the future keys don't exist yet (so they are perfectly secure! 😉), and would be created when the new release is issued. The advantage of multiple keys signing the tree head is that old clients wouldn't break (unless we want them to).

Sorry, I'm a bit confused. Let's say that before time N, online key 1 was used. At time N, online key is compromised. After time N, a new Go release is issued to trust online key 2 instead.

In order to preserve backwards-compatibility with older Go clients, is the expectation that both online keys 1 and 2 will be used going forward to sign the MHT? Or not, in this case, because online key 1 was compromised, and so Go will break signatures for older clients? In what conditions will multiple signing keys be used?

trishankatdatadog

comment created time in 13 days

delete branch trishankatdatadog/peps

delete branch : pep458/update-authors

delete time in 13 days

more