Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 04 09:50
    LucianoBestia commented #429
  • Dec 03 17:37
    Minoru commented #429
  • Dec 02 15:51

    kornelski on master

    Bump deps (compare)

  • Dec 02 13:50
    LucianoBestia opened #429
  • Dec 02 13:46
    LucianoBestia commented #373
  • Dec 02 13:45
    LucianoBestia commented #373
  • Nov 26 19:56

    kornelski on master

    MSRV (compare)

  • Nov 26 17:28

    kornelski on master

    Fallback for unconfigured git n… (compare)

  • Nov 26 14:26

    kornelski on master

    Fallback for git2 repo init (compare)

  • Nov 25 13:10

    kornelski on master

    Test output (compare)

  • Nov 25 11:34

    kornelski on master

    Remove obsolete flag (compare)

  • Nov 24 22:30

    kornelski on master

    Clippy (compare)

  • Nov 24 19:28

    kornelski on master

    Syntax fix Clippy (compare)

  • Nov 24 19:02

    kornelski on master

    Less noisy sanitized review dirs Bump deps (compare)

  • Nov 24 18:57
    p-avital commented #428
  • Nov 24 17:49
    dpc commented #428
  • Nov 24 17:46
    dpc commented #428
  • Nov 24 17:45
    dpc commented #428
  • Nov 24 17:43
    dpc commented #428
  • Nov 24 17:17
    p-avital opened #428
dpc
@dpc:matrix.org
[m]
BTW. It looks to me like in-toto attestations are not very human-readable, which seems unfortunate.
Here is an example of differential-review, and also meta-data suggesting alternatives to the crate being reviewed (for discoverability, etc.) https://github.com/dpc/crev-proofs/blob/56ab2ddc1bcc97066fe1545b9f492505f30c22c6/FYlr8YoYGVvDwHQxqEIs89reKKDy-oWisoO0qXXEfHE/reviews/2020-02-package-Q3tr4A.proof.crev#L23
Aditya Sirish
@saky:matrix.org
[m]

BTW. It looks to me like in-toto attestations are not very human-readable, which seems unfortunate.

I think there's a bit of a balance between the information they contain and how readable they are. :\ any specific examples that seemed particularly unreadable to you? Always happy to hear feedback on how to improve things.

Thanks for the links! I'm going to take them as homework for tonight / this weekend
dpc
@dpc:matrix.org
[m]
Aditya Sirish: How exactly are these attestations signed over?
Aditya Sirish
@saky:matrix.org
[m]
I think I need a bit more context for that. Each metadata is signed by the person / machine capturing it. We support a few different signing algorithms, as well as gpg and recently support for certificates. It's a bit of an implementation detail rather than part of the in-toto spec itself.
dpc
@dpc:matrix.org
[m]
My question is more about the inline signing that looks suspicious to me.
As you can see in the crev proofs there's a signing envelope, and content is signed as serialized text.
That avoids the weird and complex inline-json signing schemes that I've seen in the past around, which always seemed like a bad idea.
Aditya Sirish
@saky:matrix.org
[m]
so in-toto is in a transitionary phase when it comes to the signature wrapper. We used to sign metadata represented as canonical json, but we're working on switching to DSSE https://github.com/secure-systems-lab/dsse
The old signature envelope was originally designed as part of the TUF project (https://theupdateframework.io/
)
DSSE avoids some of the downsides of the old wrapper.
We also are wrapper agnostic, to be honest, because different adopters have different opinions about what they want to use. So we recently defined an enhancement that proposes certain properties rather than any one wrapper.
dpc
@dpc:matrix.org
[m]
Stuff as described in discussion here https://news.ycombinator.com/item?id=20516649
Aditya Sirish
@saky:matrix.org
[m]
I think that's a good example of the change in progress. We used https://wiki.laptop.org/go/Canonical_JSON as the format pre signing / verifying, but with DSSE we'd focus on the bytes rather than JSON itself.
dpc
@dpc:matrix.org
[m]
Oh dear. People will just justify any complexity just to arbitrarily avoid leaving JSON. :/
Aditya Sirish
@saky:matrix.org
[m]
ITE-5 specifically calls for not requiring canonicalization for verification, because of the risks it may pose.
we're trying to remain agnostic about the formats implementers want to use, and rather focusing on the data they capture, and how that's all verified. I know there's some interest in using non json formats for example, and ITE-5 opens the door to that.
Aditya Sirish
@saky:matrix.org
[m]
i'm not sure i have a personal stance on which wireline format to use tbh, but rather which ones I dislike for one reason or another 😆
dpc
@dpc:matrix.org
[m]
It's rather irrelevant tangent that I couldn't help myself not to comment on.
Aditya Sirish
@saky:matrix.org
[m]
hahaha
dpc
@dpc:matrix.org
[m]
Anyway, we can stay in touch and I'm happy to answer some questions and share some opinions.
I'd be happy to see the messed up world of software ecosystem to get a little bit more secure.
Aditya Sirish
@saky:matrix.org
[m]
\I'll go do my homework, and post any questions I may have here. Thanks for the resources and the discussion!

I'd be happy to see the messed up world of software ecosystem to get a little bit more secure.

big +1 from me :)

kpcyrd
@kpcyrd:archlinux.org
[m]
Is there a way to make cargo crev verify fail if there are crates other than pass and local?
dpc
@dpc:matrix.org
[m]
kpcyrd: Isn't that already the case (the return code?)
kpcyrd
@kpcyrd:archlinux.org
[m]
It exits with 0 for me
dpc
@dpc:matrix.org
[m]
What other statuses you have?
kpcyrd: I'm looking at the code, verify_deps in src/deps.rs and it should return failure if there's any crate that is not verified.
    Ok(if nb_unverified == 0 {
        CommandExitStatus::Success
    } else {
        CommandExitStatus::VerificationFailed
    })
kpcyrd
@kpcyrd:archlinux.org
[m]
dpc: https://github.com/crev-dev/cargo-crev/blob/v0.21.3/cargo-crev/src/main.rs#L630 there's a return missing here, the CommandExitStatus is discarded by the semicolon
dpc
@dpc:matrix.org
[m]
kpcyrd: 🎉
#[must_use] would have prevented it. You're OK to push a PR? kpcyrd
kpcyrd
@kpcyrd:archlinux.org
[m]
yes, preparing one now
dpc
@dpc:matrix.org
[m]
❤️thanks for looking into it
kpcyrd
@kpcyrd:archlinux.org
[m]
happy to help :)
kpcyrd
@kpcyrd:archlinux.org
[m]
hm, it seems #[must_use] doesn't generate a warning because the result is used, but the inner value isn't
dpc
@dpc:matrix.org
[m]
Can't #[must_use] be on a type of CommandExitStatus ?
I don't know the details of #[must_use] so I was just guessing. :D
Or does it work, but just not warn anyway.
? is using the Result, ; is discarding the CommandExitStatus. That's my understanding.
kpcyrd
@kpcyrd:archlinux.org
[m]
I added it on the function, adding it to the enum worked :)
The suggested cargo fmt command rewrites a bunch of unrelated files because the default format rules changed, I think
So I skipped that part
dpc
@dpc:matrix.org
[m]
👍️ Thanks!