certifi / gocertifi Goto Github PK

What would folks think about adding cacerts.pem to the repo and having gocertifi read it from disk on execution? This is kind of the approach of python-certifi.

This would allow us to get rid of tasks.py and replace it with a simple curl command to update cacerts.pem. To be fair, this would add the complexity of reading a file from disk, but I don't think that's totally unreasonable.

Just a thought. Cheers!

Tested on both old and fresh project didn't work

Go get error:
go: github.com/certifi/gocertifi: no matching versions for query "upgrade"

Go mod tidy error:
github.com/certifi/gocertifi: no matching versions for query "latest"

Hi there,

I'm trying to download

https://app.cypresstruck.com/appResources.js

and I'm passing gocertifi in transport layer. I get the error

x509: certificate signed by unknown authority

but, this works from Chrome Browser - saying it is from Go Daddy signed. What am I missing here?

Hello,

there is a statement in README that the CA bundle is the same as in requests library. However, 15 CAs are missing. There should be a sync or, preferably, automatic download from Mozilla.
Here are the missing certs' sha1 sums:
99:a6:9b:e6:1a:fe:88:6b:4d:2b:82:00:7c:b8:54:fc:31:7e:15:39 31:7a:2a:d0:7f:2b:33:5e:f5:a1:c3:4e:4b:57:e8:b7:d8:f1:fc:a6 e3:92:51:2f:0a:cf:f5:05:df:f6:de:06:7f:75:37:e1:65:ea:57:4b 87:9f:4b:ee:05:df:98:58:3b:e3:60:d6:33:e7:0d:3f:fe:98:71:af 69:bd:8c:f4:9c:d3:00:fb:59:2e:17:93:ca:55:6a:f3:ec:aa:35:fb e5:df:74:3c:b6:01:c4:9b:98:43:dc:ab:8c:e8:6a:81:10:9f:e4:8e da:40:18:8b:91:89:a3:ed:ee:ae:da:97:fe:2f:9d:f5:b7:d1:8a:41 7e:78:4a:10:1c:82:65:cc:2d:e1:f1:6d:47:b4:40:ca:d9:0a:19:45 62:7f:8d:78:27:65:63:99:d2:7d:7f:90:44:c9:fe:b3:f3:3e:fa:9a 23:e5:94:94:51:95:f2:41:48:03:b4:d5:64:d2:a3:a3:f5:d8:8b:8c 74:2c:31:92:e6:07:e4:24:eb:45:49:54:2b:e1:bb:c5:3e:61:74:e2 a1:db:63:93:91:6f:17:e4:18:55:09:40:04:15:c7:02:40:b0:ae:6b 85:37:1c:a6:e5:50:14:3d:ce:28:03:47:1b:de:3a:09:e8:f8:77:0f 97:81:79:50:d8:1c:96:70:cc:34:d8:09:cf:79:44:31:36:7e:f4:74 d2:32:09:ad:23:d3:14:23:21:74:e4:0d:7f:9d:62:13:97:86:63:3a

@Lukasa I'm not sure who all has permission, but I don't. So mind doing this or handing over the keys so I can? 😎

Thanks!

I think we definitely want to go this route: https://github.com/github/renaming#renaming-existing-branches so it doesn't break existing users that depended on master,

It is not helpful to have automated commits of regeneration where no certificates changes happened, but instead only timestamp changes.

So the Github Actions workflow should check that the diff has at least more than 2 lines that changed.

Parsability of the certificates should be checked by the unit test.
At runtime this check is supposed to have passed, so no error should occur in AppendCertsFromPEM and any error happening is a problem that should have been caught at build time of the program embedding gocertifi and reporting such error as panic would be appropriate.

While the repo is MPL2
https://github.com/certifi/gocertifi

From certifi.go:

// CACerts builds an X.509 certificate pool containing the
// certificate bundle from https://mkcert.org/generate/ fetch on 2021-05-07 14:14:36.874796853 -0700 PDT m=+0.476299993.

This is already 1.5 years old.

So just an idle thought: it seems idiomatic in Go to return two values as the result of an operation: the result and an error indicator (e.g. checking for a key/value in a map). So, instead of either returning a pool or nil as we do now

func CACerts() *x509.CertPool {
    pool := x509.NewCertPool()
    ok := pool.AppendCertsFromPEM([]byte(pemcerts))
    if !ok {
        return nil
    }
    return pool
}

We could consider

func CACerts() (*x509.CertPool, error) {
    pool := x509.NewCertPool()
    ok := pool.AppendCertsFromPEM([]byte(pemcerts))
    if !ok {
        return pool, fmt.Errorf("no certificates were successfully parsed")
    }
    return pool, nil
}

The benefit being that users can check for errors using the common if err != nil {... idiom plus have a useful error message to guide them, if something fails.

That having been said, I'm not sure if that helps meet the library goal of "being as easy as possible" or not as a user could ignore the error value and continue working with an empty pool. Anyhow, just a thought that I figured I'd share. Cheers!

Some Windows 10 machines are having problems connecting to a https server with Let's Encrypt cert (api.wakatime.com):
wakatime/wakatime-cli#385

The necessary cert is included in gocertifi (DST Root CA X3) but somehow it's not working in certain Windows environments.

If it makes a difference, the api.wakatime.com cert is signed by chaining an Intermediate certificate authority. That's the default for LetsEncrypt, and is working on most Windows 10 machines except the few that experience this error.

The code using gocertifi certs is here:
https://github.com/wakatime/wakatime-cli/blob/7c3c4167ec2003639a00effa34c157d0ddcd34d8/pkg/api/option.go#L167

hi, the certificates embedded in gocertifi.go seem to be out of date, about a year old!

That's a little tricky for a module that is supposed to give you 'proper' certs.