chore: fix spelling errors (#2352)

docs/community/maintainer/triage.md

@@ -188,7 +188,7 @@ We use two labels [help wanted](https://github.com/aquasecurity/trivy/issues?q=i
 and [good first issue](https://github.com/aquasecurity/trivy/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
 to identify issues that have been specially groomed for new contributors.
 
-We have specific [guidelines](/docs/docs/advanced/contribd/contrib/help-wanted.md)
+We have specific [guidelines](/docs/community/maintainer/help-wanted.md)
 for how to use these labels. If you see an issue that satisfies these
 guidelines, you can add the `help wanted` label and the `good first issue` label.
 Please note that adding the `good first issue` label must also 

docs/docs/integrations/github-actions.md

@@ -1,6 +1,6 @@
 # GitHub Actions
 
-- Here is the [Trivy Github Action][action]
+- Here is the [Trivy GitHub Action][action]
 - The Microsoft Azure team have written a [container-scan action][azure] that uses Trivy and Dockle
 - For full control over the options specified to Trivy, this [blog post][blog] describes adding Trivy into your own GitHub action workflows 
 

docs/docs/integrations/gitlab-ci.md

@@ -111,7 +111,7 @@ container_scanning:
 [example]: https://gitlab.com/aquasecurity/trivy-ci-test/pipelines
 [repository]: https://github.com/aquasecurity/trivy-ci-test
 
-### Gitlab CI alternative template
+### GitLab CI alternative template
 
 Depending on the edition of gitlab you have or your desired workflow, the
 container scanning template may not meet your needs. As an addition to the
@@ -174,8 +174,8 @@ be necessary to rename the artifact if you want to reuse the name. To then
 combine the previous artifact with the output of trivy, the following `jq`
 command can be used, `jq -s 'add' prev-codeclimate.json trivy-codeclimate.json > gl-codeclimate.json`.
 
-### Gitlab CI alternative template example report
+### GitLab CI alternative template example report
 
-You'll be able to see a full report in the Gitlab pipeline code quality UI, where filesystem vulnerabilities and misconfigurations include links to the flagged files and image vulnerabilities report the image/os or runtime/library that the vulnerability originates from instead.
+You'll be able to see a full report in the GitLab pipeline code quality UI, where filesystem vulnerabilities and misconfigurations include links to the flagged files and image vulnerabilities report the image/os or runtime/library that the vulnerability originates from instead.
 
 ![codequality](../../imgs/gitlab-codequality.png)

docs/docs/kubernetes/cli/scanning.md

@@ -27,7 +27,7 @@ Filter by severity:
 $ trivy k8s --severity=CRITICAL --report=all cluster
 ```
 
-Filter by security check (Vulnerabilties, Secrets or Misconfigurations):
+Filter by security check (Vulnerabilities, Secrets or Misconfigurations):
 
 ```
 $ trivy k8s --security-checks=secret --report=summary cluster

docs/docs/kubernetes/operator/troubleshooting.md

@@ -65,11 +65,11 @@ Make sure that you are providing the right resources upon installing the Trivy O
 If your pod is in `CrashLoopBackOff`, it is likely the case that the pod cannot be scheduled on the Kubernetes node that it is trying to schedule on.
 In this case, you want to investigate further whether there is an issue with the node. It could for instance be the case that the node does not have sufficient resources.
 
-## Reconcilation Error
+## Reconciliation Error
 
 It could happen that the pod appears to be running normally but does not reconcile the resources inside of your Kubernetes cluster.
 
-Check the logs for reconcilation errors:
+Check the logs for reconciliation errors:
 ```
 kubectl logs deployment/trivy-operator -n trivy-system
 ```

docs/docs/misconfiguration/custom/examples.md

@@ -6,7 +6,7 @@ See [here][k8s].
 
 The custom policy is defined in `user.kubernetes.ID001` package.
 You need to pass the package prefix you want to evaluate through `--namespaces` option.
-In this case, the package prefix should be `user`, `user.kuberntes`, or `user.kubernetes.ID001`.
+In this case, the package prefix should be `user`, `user.kubernetes`, or `user.kubernetes.ID001`.
 
 ### Dockerfile
 See [here][dockerfile].

docs/docs/misconfiguration/policy/builtin.md

@@ -16,7 +16,7 @@ Those policies are managed under [defsec repository][defsec].
 
 For suggestions or issues regarding policy content, please open an issue under the [defsec][defsec] repository.
 
-Helm Chart scanning will resolve the chart to Kubernetes manifests then run the [kubenetes][kubernetes] checks.
+Helm Chart scanning will resolve the chart to Kubernetes manifests then run the [kubernetes][kubernetes] checks.
 
 Ansible scanning is coming soon.
 

docs/docs/vulnerability/scanning/git-repository.md

@@ -112,7 +112,7 @@ Total: 20 (UNKNOWN: 3, LOW: 0, MEDIUM: 7, HIGH: 5, CRITICAL: 5)
 |                     |                  |          |                   |                        | 2.11.3. The ReDOS...                  |
 +---------------------+------------------+----------+-------------------+------------------------+---------------------------------------+
 | py                  | CVE-2020-29651   | HIGH     | 1.8.0             |                        | python-py: ReDoS in the py.path.svnwc |
-|                     |                  |          |                   |                        | component via mailicious input        |
+|                     |                  |          |                   |                        | component via malicious input         |
 |                     |                  |          |                   |                        | to blame functionality...             |
 |                     |                  |          |                   |                        | -->avd.aquasec.com/nvd/cve-2020-29651 |
 +---------------------+------------------+----------+-------------------+------------------------+---------------------------------------+

docs/index.md

@@ -22,17 +22,17 @@ All you need to do for scanning is to specify a target such as an image name of
     <h1 id="demo">Demo</h1>
 </div>
 
-<figure style="text-aligh: center">
+<figure style="text-align: center">
   <img src="imgs/vuln-demo.gif" width="1000">
   <figcaption>Demo: Vulnerability Detection</figcaption>
 </figure>
 
-<figure style="text-aligh: center">
+<figure style="text-align: center">
   <img src="imgs/misconf-demo.gif" width="1000">
   <figcaption>Demo: Misconfiguration Detection</figcaption>
 </figure>
 
-<figure style="text-aligh: center">
+<figure style="text-align: center">
   <img src="imgs/secret-demo.gif" width="1000">
   <figcaption>Demo: Secret Detection</figcaption>
 </figure>

helm/trivy/README.md

@@ -18,7 +18,7 @@ This chart bootstraps a Trivy deployment on a [Kubernetes](http://kubernetes.io)
 - Kubernetes 1.12+
 - Helm 3+
 
-## Installing from the the Aqua Chart Repository
+## Installing from the Aqua Chart Repository
 
 ```
 helm repo add aquasecurity https://aquasecurity.github.io/helm-charts/

integration/client_server_test.go

@@ -225,7 +225,7 @@ func TestClientServer(t *testing.T) {
 			golden: "testdata/mariner-1.0.json.golden",
 		},
 		{
-			name: "buxybox with Cargo.lock",
+			name: "busybox with Cargo.lock",
 			args: csArgs{
 				Input: "testdata/fixtures/images/busybox-with-lockfile.tar.gz",
 			},

integration/standalone_tar_test.go

@@ -240,7 +240,7 @@ func TestTar(t *testing.T) {
 			golden: "testdata/mariner-1.0.json.golden",
 		},
 		{
-			name: "buxybox with Cargo.lock integration",
+			name: "busybox with Cargo.lock integration",
 			testArgs: args{
 				Format: "json",
 				Input:  "testdata/fixtures/images/busybox-with-lockfile.tar.gz",

integration/testdata/almalinux-8.json.golden

@@ -68,7 +68,7 @@
             "URL": "https://errata.almalinux.org/"
           },
           "Title": "openssl: Read buffer overruns processing ASN.1 strings",
-          "Description": "ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own \"d2i\" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the \"data\" and \"length\" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the \"data\" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).",
+          "Description": "ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are represented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own \"d2i\" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the \"data\" and \"length\" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the \"data\" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).",
           "Severity": "MEDIUM",
           "CweIDs": [
             "CWE-125"

integration/testdata/fixtures/db/vulnerability.yaml

@@ -887,7 +887,7 @@
           V3Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
       CweIDs:
       - CWE-502
-      Description: A deserialization of untrusted data vulnernerability exists in rails < 5.2.4.3, rails < 6.0.3.1 that can allow an attacker to unmarshal user-provided objects in MemCacheStore and RedisCacheStore potentially resulting in an RCE.
+      Description: A deserialization of untrusted data vulnerability exists in rails < 5.2.4.3, rails < 6.0.3.1 that can allow an attacker to unmarshal user-provided objects in MemCacheStore and RedisCacheStore potentially resulting in an RCE.
       LastModifiedDate: 2020-10-17T12:15:00Z
       PublishedDate: 2020-06-19T18:15:00Z
       References:
@@ -998,7 +998,7 @@
           V3Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H
       CweIDs:
       - CWE-125
-      Description: ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
+      Description: ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are represented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
       LastModifiedDate: 2022-01-06T09:15:00Z
       PublishedDate: 2021-08-24T15:15:00Z
       References:

integration/testdata/fluentd-gems.json.golden

@@ -186,7 +186,7 @@
             "URL": "https://github.com/advisories?query=type%3Areviewed+ecosystem%3Arubygems"
           },
           "Title": "rubygem-activesupport: potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore",
-          "Description": "A deserialization of untrusted data vulnernerability exists in rails \u003c 5.2.4.3, rails \u003c 6.0.3.1 that can allow an attacker to unmarshal user-provided objects in MemCacheStore and RedisCacheStore potentially resulting in an RCE.",
+          "Description": "A deserialization of untrusted data vulnerability exists in rails \u003c 5.2.4.3, rails \u003c 6.0.3.1 that can allow an attacker to unmarshal user-provided objects in MemCacheStore and RedisCacheStore potentially resulting in an RCE.",
           "Severity": "HIGH",
           "CweIDs": [
             "CWE-502"

integration/testdata/rockylinux-8.json.golden

@@ -68,7 +68,7 @@
             "URL": "https://download.rockylinux.org/pub/rocky/"
           },
           "Title": "openssl: Read buffer overruns processing ASN.1 strings",
-          "Description": "ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own \"d2i\" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the \"data\" and \"length\" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the \"data\" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).",
+          "Description": "ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are represented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own \"d2i\" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the \"data\" and \"length\" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the \"data\" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).",
           "Severity": "MEDIUM",
           "CweIDs": [
             "CWE-125"

pkg/commands/artifact/run.go

@@ -73,7 +73,7 @@ type Runner interface {
 	ScanFilesystem(ctx context.Context, opt Option) (types.Report, error)
 	// ScanRootfs scans rootfs
 	ScanRootfs(ctx context.Context, opt Option) (types.Report, error)
-	// ScanRepositroy scans repository
+	// ScanRepository scans repository
 	ScanRepository(ctx context.Context, opt Option) (types.Report, error)
 	// Filter filter a report
 	Filter(ctx context.Context, opt Option, report types.Report) (types.Report, error)

pkg/detector/ospkg/redhat/redhat.go

@@ -97,7 +97,7 @@ func NewScanner(opts ...option) *Scanner {
 	}
 }
 
-// Detect scans and returns redhat vulenrabilities
+// Detect scans and returns redhat vulnerabilities
 func (s *Scanner) Detect(osVer string, _ *ftypes.Repository, pkgs []ftypes.Package) ([]types.DetectedVulnerability, error) {
 	log.Logger.Info("Detecting RHEL/CentOS vulnerabilities...")
 	if strings.Count(osVer, ".") > 0 {

pkg/rpc/client/client_test.go

@@ -71,7 +71,7 @@ func TestScanner_Scan(t *testing.T) {
 								Title:            "DoS",
 								Description:      "Denial os Service",
 								Severity:         common.Severity_CRITICAL,
-								References:       []string{"http://exammple.com"},
+								References:       []string{"http://example.com"},
 								SeveritySource:   "nvd",
 								VendorSeverity: map[string]common.Severity{
 									string(vulnerability.NVD):    common.Severity_MEDIUM,
@@ -119,7 +119,7 @@ func TestScanner_Scan(t *testing.T) {
 								Title:       "DoS",
 								Description: "Denial os Service",
 								Severity:    "CRITICAL",
-								References:  []string{"http://exammple.com"},
+								References:  []string{"http://example.com"},
 								VendorSeverity: dbTypes.VendorSeverity{
 									vulnerability.NVD:    dbTypes.SeverityMedium,
 									vulnerability.RedHat: dbTypes.SeverityMedium,

pkg/rpc/server/server.go

@@ -53,7 +53,7 @@ type CacheServer struct {
 	cache cache.Cache
 }
 
-// NewCacheServer is the facotry method for cacheServer
+// NewCacheServer is the factory method for cacheServer
 func NewCacheServer(c cache.Cache) *CacheServer {
 	return &CacheServer{cache: c}
 }

rpc/cache/service.twirp.go

@@ -1469,8 +1469,8 @@ func writeError(ctx context.Context, resp http.ResponseWriter, err error, hooks
 	callResponseSent(ctx, hooks)
 }
 
-// sanitizeBaseURL parses the the baseURL, and adds the "http" scheme if needed.
+// sanitizeBaseURL parses the baseURL, and adds the "http" scheme if needed.
-// If the URL is unparsable, the baseURL is returned unchaged.
+// If the URL is unparsable, the baseURL is returned unchanged.
 func sanitizeBaseURL(baseURL string) string {
 	u, err := url.Parse(baseURL)
 	if err != nil {

rpc/scanner/service.twirp.go

@@ -630,8 +630,8 @@ func writeError(ctx context.Context, resp http.ResponseWriter, err error, hooks
 	callResponseSent(ctx, hooks)
 }
 
-// sanitizeBaseURL parses the the baseURL, and adds the "http" scheme if needed.
+// sanitizeBaseURL parses the baseURL, and adds the "http" scheme if needed.
-// If the URL is unparsable, the baseURL is returned unchaged.
+// If the URL is unparsable, the baseURL is returned unchanged.
 func sanitizeBaseURL(baseURL string) string {
 	u, err := url.Parse(baseURL)
 	if err != nil {