Release 1.0 planning about fulcio HOT 11 CLOSED

I have been thinking the same. fuclio has been operating in a stable manner for a while now. I will freeze the milestone and we can look at closing the release.

cc @cpanato

Let's chat on Monday about shipping.

from fulcio.

The googleca stuff needs to move to the 1.0 API

from fulcio.

@cpanato as I understand, it won't be a change of flags or a non backwards compatible change.

At the moment we have a pattern of folks making proposals to add to 1.0, but not able to do the work and so we are seeing 1.0 pushed back and a moving target. For me the most important role of fulcio is the public good instance and what we have at present, which although I am sure can be improved over time, is currently functioning well.

from fulcio.

ahh got it, i think i misunderstood :(

from fulcio.

same from rekor:

I would like to add a cloudbuild + goreleaser when we release Fulcio

then I have some questions:

1. We will use the same KMS key that we use to sign cosign? or we create another?
2. To push the data to the Rekor server how can we do that in an automated fashion way? there is any guide? or we just don't do it at this time?

@dlorenc @lukehinds @dekkagaijin

from fulcio.

We will use the same KMS key that we use to sign cosign? or we create another?

Subscribing myself here -- if we do add a new one I need to add it to our root

from fulcio.

Another one that came up with the keyless attestation breakage is that Let's Encrypt has a staging endpoint for tool developers to use to test against without worrying about stuff like quota, and doesn't use the actual CA cert as the root.

Given that we can't even properly test things in cosign against Fulcio pre-submit, I think this is going to be a problem for tooling developers looking to integrate with cosign/fulcio.

I won't outline all of my thoughts on this here, but if folks agree that it's a worthy v1 blocker, then we should open a parallel issue to track it.

cc @dlorenc @n3wscott @lukehinds

from fulcio.

Should probably lock down the configuration prior to 1.0: #304

from fulcio.

Not 100% configuration change should be 1.0 blocker. If only because it seems like it might take some time to finish up a refactor. I discussed it a bit here: #304 (comment)

from fulcio.

if need to change any configuration, maybe we can do that now and make a pre-release with deprecations and then plan the 1.0 removing the deprecations.

from fulcio.

Everything here has been completed. Additional work is tracked here - https://github.com/orgs/sigstore/projects/5/views/1

from fulcio.