Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
Hi Reinhard, absolutely no worries at all! Huge thanks on all your work and sorry for not being more responsive. I can only manage some "debian time" in between "real life" blocks, so a lot falls through the cracks :( Cheers Leo --- Original Message --- On Wednesday, July 19th, 2023 at 12:35, Reinhard Tartler wrote: > Hi Leo, > > I hope you are well. Now that all dependencies to build this package are in > place, I've taken the liberty of uploading the package to debian/experimental > and pushed my sources to > https://salsa.debian.org/go-team/packages/golang-github-sigstore-sigstore > > I really don't want this to be seen as an ITP takeover, since we've been > talking on this ITP for a while, I hope that's okay. Please take a look at > this repo and at > https://ftp-master.debian.org/new/golang-github-sigstore-sigstore_1.4.0-1.html > and let me know what you think. > > Best, > -rt > -- > > regards, > Reinhard
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
Hi Leo, I hope you are well. Now that all dependencies to build this package are in place, I've taken the liberty of uploading the package to debian/experimental and pushed my sources to https://salsa.debian.org/go-team/packages/golang-github-sigstore-sigstore I really don't want this to be seen as an ITP takeover, since we've been talking on this ITP for a while, I hope that's okay. Please take a look at this repo and at https://ftp-master.debian.org/new/golang-github-sigstore-sigstore_1.4.0-1.html and let me know what you think. Best, -rt -- regards, Reinhard
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
On Thu, Apr 13, 2023 at 6:46 AM Reinhard Tartler wrote: > > -- unfortunately, I made a mistake: I packaged version 3 of > jellydator-ttlcache, which has a significantly different API than version2, > which sigstore currently uses. > > I'm considering either downgrading the package, or making sigstore use v3. > I guess the latter is better in the long term. Mh. > > https://github.com/sigstore/sigstore/pull/1099 to make up for that mistake -- regards, Reinhard
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
On Wed, Apr 12, 2023 at 3:53 PM Leo Antunes wrote:
> Sorry for the late reply. My laptop decided it was a good time to break,
> so I'll have even less time to work on this in the next few days/weeks :/
>
> --- Original Message ---
> On Sunday, March 26th, 2023 at 22:07, Reinhard Tartler
> wrote:
>
> > Sounds good.
> >
> > I'm happy to take on the easier dependencies, such as pkg/browser or
> jellydator/ttlcache.
>
>
> That would be a huge help already!
>
>
https://tracker.debian.org/pkg/golang-github-jellydator-ttlcache
https://tracker.debian.org/pkg/golang-github-pkg-browser
you're welcome :-)
-- unfortunately, I made a mistake: I packaged version 3 of
jellydator-ttlcache, which has a significantly different API than version2,
which sigstore currently uses.
I'm considering either downgrading the package, or making sigstore use v3.
I guess the latter is better in the long term. Mh.
> > But the dependency on boulder is giving me a massive headache. It is
> really unfortunate that they chose to use such a heavy dependency for a
> rather simple task (goodkey). What are your thoughts on resolving this?
>
>
> I didn't dive deep into the code, but I suspect we can patch away the
> boulder dep. I'll gladly give it a try as soon as I have a workable laptop
> again (but feel free to jump in if you find the time!)
>
>
I think this patch should do it:
modified pkg/cryptoutils/publickey.go
@@ -16,7 +16,6 @@
package cryptoutils
import (
- "context"
"crypto"
"crypto/ecdsa"
"crypto/ed25519"
@@ -30,8 +29,6 @@ import (
"encoding/pem"
"errors"
"fmt"
-
- "github.com/letsencrypt/boulder/goodkey"
)
const (
@@ -139,20 +136,8 @@ func genErrMsg(first, second crypto.PublicKey, keyType
string) string {
func ValidatePubKey(pub crypto.PublicKey) error {
switch pk := pub.(type) {
case *rsa.PublicKey:
- // goodkey policy enforces:
- // * Size of key: 2048 <= size <= 4096, size % 8 = 0
- // * Exponent E = 65537 (Default exponent for OpenSSL and Golang)
- // * Small primes check for modulus
- // * Weak keys generated by Infineon hardware (see
https://crocs.fi.muni.cz/public/papers/rsa_ccs17)
- // * Key is easily factored with Fermat's factorization method
- p, err := goodkey.NewKeyPolicy({FermatRounds: 100}, nil)
- if err != nil {
- // Should not occur, only chances to return errors are if fermat rounds
- // are <0 or when loading blocked/weak keys from disk (not used here)
- return errors.New("unable to initialize key policy")
- }
- // ctx is unused
- return p.GoodKey(context.Background(), pub)
+ // Avoid dependency on Goodkey for debian
+ return nil;
case *ecdsa.PublicKey:
// Unable to use goodkey policy because P-521 curve is not supported
return validateEcdsaKey(pk)
modified pkg/cryptoutils/publickey_test.go
@@ -183,6 +183,8 @@ func TestValidatePubKeyUnsupported(t *testing.T) {
}
func TestValidatePubKeyRsa(t *testing.T) {
+ t.Skip("Validations disabled for Debian")
+
// Validate common RSA key sizes
for _, bits := range []int{2048, 3072, 4096} {
priv, err := rsa.GenerateKey(rand.Reader, bits)
--
regards,
Reinhard
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
Sorry for the late reply. My laptop decided it was a good time to break, so I'll have even less time to work on this in the next few days/weeks :/ --- Original Message --- On Sunday, March 26th, 2023 at 22:07, Reinhard Tartler wrote: > Sounds good. > > I'm happy to take on the easier dependencies, such as pkg/browser or > jellydator/ttlcache. That would be a huge help already! > But the dependency on boulder is giving me a massive headache. It is really > unfortunate that they chose to use such a heavy dependency for a rather > simple task (goodkey). What are your thoughts on resolving this? I didn't dive deep into the code, but I suspect we can patch away the boulder dep. I'll gladly give it a try as soon as I have a workable laptop again (but feel free to jump in if you find the time!) Regards, Leo Antunes
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
Sounds good. I'm happy to take on the easier dependencies, such as pkg/browser or jellydator/ttlcache. But the dependency on boulder is giving me a massive headache. It is really unfortunate that they chose to use such a heavy dependency for a rather simple task (goodkey). What are your thoughts on resolving this? -rt On Sun, Feb 5, 2023 at 3:30 PM Leo Antunes wrote: > Hi Reinhard, > > It seems I underestimated the work and overestimated by free time: we need > some bumps for deps (e.g. golang-github-azure-azure-sdk-for-go-dev) and > maybe some patching to get rid of other deps (e.g. > github.com/letsencrypt/boulder), if we can manage that. > OTOH, I see you already took care of #1030555 and #1030557! That's great! > :) > > Cheers > Leo > > > --- Original Message --- > On Thursday, February 2nd, 2023 at 12:33, Reinhard Tartler < > siret...@gmail.com> wrote: > > > > seems https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022937 was > accepted. Any update on sigstore packaging? > > > -- regards, Reinhard
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
Hi Reinhard, It seems I underestimated the work and overestimated by free time: we need some bumps for deps (e.g. golang-github-azure-azure-sdk-for-go-dev) and maybe some patching to get rid of other deps (e.g. github.com/letsencrypt/boulder), if we can manage that. OTOH, I see you already took care of #1030555 and #1030557! That's great! :) Cheers Leo --- Original Message --- On Thursday, February 2nd, 2023 at 12:33, Reinhard Tartler wrote: > seems https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022937 was accepted. > Any update on sigstore packaging?
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
seems https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022937 was accepted. Any update on sigstore packaging? On Fri, Jan 20, 2023 at 9:47 AM Reinhard Tartler wrote: > Awesome, thanks for the update! > > Skimming over the sources of sigstore, it seems to me that the awk-sdk > might be easy to disable with minor surgery. Would you be open to uploading > a sigstore package to NEW with the aws functionality disabled and re-enable > it as soon as the awk package becomes available in Debian? > > -rt > > On Fri, Jan 20, 2023 at 7:30 AM Leo Antunes wrote: > >> Hi Reinhard! >> >> I think this changed a bit in the meantime: now the sigstore project has >> mostly shared lib code, while the individual commands (rekor, fulcio, >> gitsign, etc) are all in separate repos. So I expect this library to not be >> THAT difficult to package (the next one on my list is rekor - see #990249 >> - which will probably require more work). >> As soon as #1022937 is done (waiting in NEW since 2 months), I expect >> sigstore to be a quick follow-up. >> However, I'd gladly take an extra pair of eyes on the package, so I can >> ping you as soon as I have something that builds. >> >> >> Thanks, >> Leo Antunes >> --- Original Message --- >> On Thursday, January 19th, 2023 at 09:37, Reinhard Tartler < >> siret...@gmail.com> wrote: >> >> Hi Leo, >> >> Thank you so much for your interest in packaging this! -- I've noticed >> that it is a dependency of containers/image for image signing, and have >> looked at this package before. Unfortunately, I got intimidated with the >> sheer number of unpackaged dependencies that it requires. Maybe this has >> improved since the last time I looked at it? In any case, I've decided to >> patch the source to disable signing functionality to avoid requiring code >> from sigstore, which is of course very unfortunate. >> >> Let me know if you could use another set of eyeballs or help with this >> package. It surely seems intimidating (at least to me). >> >> best, >> -rt >> >> On Wed, Jan 18, 2023 at 3:21 PM Leo Antunes wrote: >> >>> Package: wnpp >>> Severity: wishlist >>> Owner: Leo Antunes >>> >>> * Package name : golang-github-sigstore-sigstore >>> Version : 1.5.1-1 >>> Upstream Author : The Sigstore Authors >>> * URL : https://github.com/sigstore/sigstore >>> * License : Apache-2.0 >>> Programming Lang: Go >>> Description : Common go library shared across sigstore services and >>> clients >>> >>> sigstore/sigstore contains common Sigstore code: that is, code shared >>> by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g. >>> Cosign and Gitsign. >>> >>> >> >> -- >> regards, >> Reinhard >> >> >> > > -- > regards, > Reinhard > -- regards, Reinhard
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
Awesome, thanks for the update! Skimming over the sources of sigstore, it seems to me that the awk-sdk might be easy to disable with minor surgery. Would you be open to uploading a sigstore package to NEW with the aws functionality disabled and re-enable it as soon as the awk package becomes available in Debian? -rt On Fri, Jan 20, 2023 at 7:30 AM Leo Antunes wrote: > Hi Reinhard! > > I think this changed a bit in the meantime: now the sigstore project has > mostly shared lib code, while the individual commands (rekor, fulcio, > gitsign, etc) are all in separate repos. So I expect this library to not be > THAT difficult to package (the next one on my list is rekor - see #990249 > - which will probably require more work). > As soon as #1022937 is done (waiting in NEW since 2 months), I expect > sigstore to be a quick follow-up. > However, I'd gladly take an extra pair of eyes on the package, so I can > ping you as soon as I have something that builds. > > > Thanks, > Leo Antunes > --- Original Message --- > On Thursday, January 19th, 2023 at 09:37, Reinhard Tartler < > siret...@gmail.com> wrote: > > Hi Leo, > > Thank you so much for your interest in packaging this! -- I've noticed > that it is a dependency of containers/image for image signing, and have > looked at this package before. Unfortunately, I got intimidated with the > sheer number of unpackaged dependencies that it requires. Maybe this has > improved since the last time I looked at it? In any case, I've decided to > patch the source to disable signing functionality to avoid requiring code > from sigstore, which is of course very unfortunate. > > Let me know if you could use another set of eyeballs or help with this > package. It surely seems intimidating (at least to me). > > best, > -rt > > On Wed, Jan 18, 2023 at 3:21 PM Leo Antunes wrote: > >> Package: wnpp >> Severity: wishlist >> Owner: Leo Antunes >> >> * Package name : golang-github-sigstore-sigstore >> Version : 1.5.1-1 >> Upstream Author : The Sigstore Authors >> * URL : https://github.com/sigstore/sigstore >> * License : Apache-2.0 >> Programming Lang: Go >> Description : Common go library shared across sigstore services and >> clients >> >> sigstore/sigstore contains common Sigstore code: that is, code shared >> by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g. >> Cosign and Gitsign. >> >> > > -- > regards, > Reinhard > > > -- regards, Reinhard
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
Hi Reinhard! I think this changed a bit in the meantime: now the sigstore project has mostly shared lib code, while the individual commands (rekor, fulcio, gitsign, etc) are all in separate repos. So I expect this library to not be THAT difficult to package (the next one on my list is rekor - see #990249 - which will probably require more work). As soon as #1022937 is done (waiting in NEW since 2 months), I expect sigstore to be a quick follow-up. However, I'd gladly take an extra pair of eyes on the package, so I can ping you as soon as I have something that builds. Thanks, Leo Antunes --- Original Message --- On Thursday, January 19th, 2023 at 09:37, Reinhard Tartler wrote: > Hi Leo, > > Thank you so much for your interest in packaging this! -- I've noticed that > it is a dependency of containers/image for image signing, and have looked at > this package before. Unfortunately, I got intimidated with the sheer number > of unpackaged dependencies that it requires. Maybe this has improved since > the last time I looked at it? In any case, I've decided to patch the source > to disable signing functionality to avoid requiring code from sigstore, which > is of course very unfortunate. > > Let me know if you could use another set of eyeballs or help with this > package. It surely seems intimidating (at least to me). > > best, > -rt > > On Wed, Jan 18, 2023 at 3:21 PM Leo Antunes wrote: > >> Package: wnpp >> Severity: wishlist >> Owner: Leo Antunes >> >> * Package name : golang-github-sigstore-sigstore >> Version : 1.5.1-1 >> Upstream Author : The Sigstore Authors >> * URL : https://github.com/sigstore/sigstore >> * License : Apache-2.0 >> Programming Lang: Go >> Description : Common go library shared across sigstore services and clients >> >> sigstore/sigstore contains common Sigstore code: that is, code shared >> by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g. >> Cosign and Gitsign. > > -- > > regards, > Reinhard
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
Hi Leo, Thank you so much for your interest in packaging this! -- I've noticed that it is a dependency of containers/image for image signing, and have looked at this package before. Unfortunately, I got intimidated with the sheer number of unpackaged dependencies that it requires. Maybe this has improved since the last time I looked at it? In any case, I've decided to patch the source to disable signing functionality to avoid requiring code from sigstore, which is of course very unfortunate. Let me know if you could use another set of eyeballs or help with this package. It surely seems intimidating (at least to me). best, -rt On Wed, Jan 18, 2023 at 3:21 PM Leo Antunes wrote: > Package: wnpp > Severity: wishlist > Owner: Leo Antunes > > * Package name: golang-github-sigstore-sigstore > Version : 1.5.1-1 > Upstream Author : The Sigstore Authors > * URL : https://github.com/sigstore/sigstore > * License : Apache-2.0 > Programming Lang: Go > Description : Common go library shared across sigstore services and > clients > > sigstore/sigstore contains common Sigstore code: that is, code shared > by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g. > Cosign and Gitsign. > > -- regards, Reinhard
Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients
Package: wnpp Severity: wishlist Owner: Leo Antunes * Package name: golang-github-sigstore-sigstore Version : 1.5.1-1 Upstream Author : The Sigstore Authors * URL : https://github.com/sigstore/sigstore * License : Apache-2.0 Programming Lang: Go Description : Common go library shared across sigstore services and clients sigstore/sigstore contains common Sigstore code: that is, code shared by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g. Cosign and Gitsign.
