[Go] Support HTTP signature

[sebastien-rosset]

This is adding a new "HTTP signature" security schemes (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/). HTTP signatures is still a IETF draft, and hopefully it will become an official RFC this year. On one hand one may argue it shouldn’t be added because it’s still a draft, but on the other hand it is already being used by multiple products, so there may be benefits to support it. It is possible multiple organizations are independently adding the same security scheme.

Ideally one way to address the problem would be to make it possible to add new security schemes (such as HTTP signature) without being required to fork the OpenAPITools repo. But given the current code structure, it’s not clear to me how this could be achieved. Adding new security schemes involves surgery in multiple locations (Java codegen, templates, mustache tags).

I raised this point in Slack before opening the PR.

This PR depends on #4993 and #4934

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[sebastien-rosset]

There is a dependency on golang 1.10.
What is the version of golang being used to build the "go" and "go-experimental" artifacts? It looks like it is a version < 1.10. Where is this specified? What is the rule for upgrading the go version? For example, how do you decide whether it's ok to upgrade to 1.13.6? This PR uses strings.Builder, but that is defined in 1.10 and above. Should I write code to do the equivalent of strings.Builder? Or submit another PR to upgrade the version of golang?

Update: golang 1.10 dependency is no longer needed. I am using bytes.Buffer. The circleCI build environment should be improved to give better control over the version of golang, but that should be done in a separate PR.

[jimschubert]

I kicked off CircleCI again, since it failed but at quick glance it seemed unrelated to work in this PR.

[sebastien-rosset]

I just learned some people save their private key with file extensions other than ".pem", so I am going to relax the validation of the private key suffix.

[sebastien-rosset]

@antihax@bvwells@grokify@kemokemo@bkabrda

A similar implementation has been done for Python and was merged to master.

[jimschubert]

LGTM!

[jimschubert]

I've merged the linked pre-req PRs. This should be good to merge after master builds pass.

[sebastien-rosset]

This is adding a new "HTTP signature" security schemes (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/). HTTP signatures is still a IETF draft, and hopefully it will become an official RFC this year. On one hand one may argue it shouldn’t be added because it’s still a draft, but on the other hand it is already being used by multiple products, so there may be benefits to support it. It is possible multiple organizations are independently adding the same security scheme.

Ideally one way to address the problem would be to make it possible to add new security schemes (such as HTTP signature) without being required to fork the OpenAPITools repo. But given the current code structure, it’s not clear to me how this could be achieved. Adding new security schemes involves surgery in multiple locations (Java codegen, templates, mustache tags).

I raised this point in Slack before opening the PR.

This PR depends on #4993 and #4934

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[sebastien-rosset]

There is a dependency on golang 1.10.
What is the version of golang being used to build the "go" and "go-experimental" artifacts? It looks like it is a version < 1.10. Where is this specified? What is the rule for upgrading the go version? For example, how do you decide whether it's ok to upgrade to 1.13.6? This PR uses strings.Builder, but that is defined in 1.10 and above. Should I write code to do the equivalent of strings.Builder? Or submit another PR to upgrade the version of golang?

Update: golang 1.10 dependency is no longer needed. I am using bytes.Buffer. The circleCI build environment should be improved to give better control over the version of golang, but that should be done in a separate PR.

[jimschubert]

I kicked off CircleCI again, since it failed but at quick glance it seemed unrelated to work in this PR.

[sebastien-rosset]

I just learned some people save their private key with file extensions other than ".pem", so I am going to relax the validation of the private key suffix.

[sebastien-rosset]

@antihax@bvwells@grokify@kemokemo@bkabrda

A similar implementation has been done for Python and was merged to master.

[jimschubert]

LGTM!

[jimschubert]

I've merged the linked pre-req PRs. This should be good to merge after master builds pass.

[sebastien-rosset]

This is adding a new "HTTP signature" security schemes (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/). HTTP signatures is still a IETF draft, and hopefully it will become an official RFC this year. On one hand one may argue it shouldn’t be added because it’s still a draft, but on the other hand it is already being used by multiple products, so there may be benefits to support it. It is possible multiple organizations are independently adding the same security scheme.

Ideally one way to address the problem would be to make it possible to add new security schemes (such as HTTP signature) without being required to fork the OpenAPITools repo. But given the current code structure, it’s not clear to me how this could be achieved. Adding new security schemes involves surgery in multiple locations (Java codegen, templates, mustache tags).

I raised this point in Slack before opening the PR.

This PR depends on #4993 and #4934

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[sebastien-rosset]

There is a dependency on golang 1.10.
What is the version of golang being used to build the "go" and "go-experimental" artifacts? It looks like it is a version < 1.10. Where is this specified? What is the rule for upgrading the go version? For example, how do you decide whether it's ok to upgrade to 1.13.6? This PR uses strings.Builder, but that is defined in 1.10 and above. Should I write code to do the equivalent of strings.Builder? Or submit another PR to upgrade the version of golang?

Update: golang 1.10 dependency is no longer needed. I am using bytes.Buffer. The circleCI build environment should be improved to give better control over the version of golang, but that should be done in a separate PR.

[jimschubert]

I kicked off CircleCI again, since it failed but at quick glance it seemed unrelated to work in this PR.

[sebastien-rosset]

I just learned some people save their private key with file extensions other than ".pem", so I am going to relax the validation of the private key suffix.

[sebastien-rosset]

@antihax@bvwells@grokify@kemokemo@bkabrda

A similar implementation has been done for Python and was merged to master.

[jimschubert]

LGTM!

[jimschubert]

I've merged the linked pre-req PRs. This should be good to merge after master builds pass.

[sebastien-rosset]

This is adding a new "HTTP signature" security schemes (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/). HTTP signatures is still a IETF draft, and hopefully it will become an official RFC this year. On one hand one may argue it shouldn’t be added because it’s still a draft, but on the other hand it is already being used by multiple products, so there may be benefits to support it. It is possible multiple organizations are independently adding the same security scheme.

Ideally one way to address the problem would be to make it possible to add new security schemes (such as HTTP signature) without being required to fork the OpenAPITools repo. But given the current code structure, it’s not clear to me how this could be achieved. Adding new security schemes involves surgery in multiple locations (Java codegen, templates, mustache tags).

I raised this point in Slack before opening the PR.

This PR depends on #4993 and #4934

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[sebastien-rosset]

There is a dependency on golang 1.10.
What is the version of golang being used to build the "go" and "go-experimental" artifacts? It looks like it is a version < 1.10. Where is this specified? What is the rule for upgrading the go version? For example, how do you decide whether it's ok to upgrade to 1.13.6? This PR uses strings.Builder, but that is defined in 1.10 and above. Should I write code to do the equivalent of strings.Builder? Or submit another PR to upgrade the version of golang?

Update: golang 1.10 dependency is no longer needed. I am using bytes.Buffer. The circleCI build environment should be improved to give better control over the version of golang, but that should be done in a separate PR.

[jimschubert]

I kicked off CircleCI again, since it failed but at quick glance it seemed unrelated to work in this PR.

[sebastien-rosset]

I just learned some people save their private key with file extensions other than ".pem", so I am going to relax the validation of the private key suffix.

[sebastien-rosset]

@antihax@bvwells@grokify@kemokemo@bkabrda

A similar implementation has been done for Python and was merged to master.

[jimschubert]

LGTM!

[jimschubert]

I've merged the linked pre-req PRs. This should be good to merge after master builds pass.

[sebastien-rosset]

This is adding a new "HTTP signature" security schemes (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/). HTTP signatures is still a IETF draft, and hopefully it will become an official RFC this year. On one hand one may argue it shouldn’t be added because it’s still a draft, but on the other hand it is already being used by multiple products, so there may be benefits to support it. It is possible multiple organizations are independently adding the same security scheme.

Ideally one way to address the problem would be to make it possible to add new security schemes (such as HTTP signature) without being required to fork the OpenAPITools repo. But given the current code structure, it’s not clear to me how this could be achieved. Adding new security schemes involves surgery in multiple locations (Java codegen, templates, mustache tags).

I raised this point in Slack before opening the PR.

This PR depends on #4993 and #4934

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[sebastien-rosset]

There is a dependency on golang 1.10.
What is the version of golang being used to build the "go" and "go-experimental" artifacts? It looks like it is a version < 1.10. Where is this specified? What is the rule for upgrading the go version? For example, how do you decide whether it's ok to upgrade to 1.13.6? This PR uses strings.Builder, but that is defined in 1.10 and above. Should I write code to do the equivalent of strings.Builder? Or submit another PR to upgrade the version of golang?

Update: golang 1.10 dependency is no longer needed. I am using bytes.Buffer. The circleCI build environment should be improved to give better control over the version of golang, but that should be done in a separate PR.

[jimschubert]

I kicked off CircleCI again, since it failed but at quick glance it seemed unrelated to work in this PR.

[sebastien-rosset]

I just learned some people save their private key with file extensions other than ".pem", so I am going to relax the validation of the private key suffix.

[sebastien-rosset]

@antihax@bvwells@grokify@kemokemo@bkabrda

A similar implementation has been done for Python and was merged to master.

[jimschubert]

LGTM!

[jimschubert]

I've merged the linked pre-req PRs. This should be good to merge after master builds pass.

[sebastien-rosset]

This is adding a new "HTTP signature" security schemes (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/). HTTP signatures is still a IETF draft, and hopefully it will become an official RFC this year. On one hand one may argue it shouldn’t be added because it’s still a draft, but on the other hand it is already being used by multiple products, so there may be benefits to support it. It is possible multiple organizations are independently adding the same security scheme.

Ideally one way to address the problem would be to make it possible to add new security schemes (such as HTTP signature) without being required to fork the OpenAPITools repo. But given the current code structure, it’s not clear to me how this could be achieved. Adding new security schemes involves surgery in multiple locations (Java codegen, templates, mustache tags).

I raised this point in Slack before opening the PR.

This PR depends on #4993 and #4934

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[sebastien-rosset]

There is a dependency on golang 1.10.
What is the version of golang being used to build the "go" and "go-experimental" artifacts? It looks like it is a version < 1.10. Where is this specified? What is the rule for upgrading the go version? For example, how do you decide whether it's ok to upgrade to 1.13.6? This PR uses strings.Builder, but that is defined in 1.10 and above. Should I write code to do the equivalent of strings.Builder? Or submit another PR to upgrade the version of golang?

Update: golang 1.10 dependency is no longer needed. I am using bytes.Buffer. The circleCI build environment should be improved to give better control over the version of golang, but that should be done in a separate PR.

[jimschubert]

I kicked off CircleCI again, since it failed but at quick glance it seemed unrelated to work in this PR.

[sebastien-rosset]

I just learned some people save their private key with file extensions other than ".pem", so I am going to relax the validation of the private key suffix.

[sebastien-rosset]

@antihax@bvwells@grokify@kemokemo@bkabrda

A similar implementation has been done for Python and was merged to master.

[jimschubert]

LGTM!

[jimschubert]

I've merged the linked pre-req PRs. This should be good to merge after master builds pass.

[sebastien-rosset]

This is adding a new "HTTP signature" security schemes (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/). HTTP signatures is still a IETF draft, and hopefully it will become an official RFC this year. On one hand one may argue it shouldn’t be added because it’s still a draft, but on the other hand it is already being used by multiple products, so there may be benefits to support it. It is possible multiple organizations are independently adding the same security scheme.

Ideally one way to address the problem would be to make it possible to add new security schemes (such as HTTP signature) without being required to fork the OpenAPITools repo. But given the current code structure, it’s not clear to me how this could be achieved. Adding new security schemes involves surgery in multiple locations (Java codegen, templates, mustache tags).

I raised this point in Slack before opening the PR.

This PR depends on #4993 and #4934

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[sebastien-rosset]

There is a dependency on golang 1.10.
What is the version of golang being used to build the "go" and "go-experimental" artifacts? It looks like it is a version < 1.10. Where is this specified? What is the rule for upgrading the go version? For example, how do you decide whether it's ok to upgrade to 1.13.6? This PR uses strings.Builder, but that is defined in 1.10 and above. Should I write code to do the equivalent of strings.Builder? Or submit another PR to upgrade the version of golang?

Update: golang 1.10 dependency is no longer needed. I am using bytes.Buffer. The circleCI build environment should be improved to give better control over the version of golang, but that should be done in a separate PR.

[jimschubert]

I kicked off CircleCI again, since it failed but at quick glance it seemed unrelated to work in this PR.

[sebastien-rosset]

I just learned some people save their private key with file extensions other than ".pem", so I am going to relax the validation of the private key suffix.

[sebastien-rosset]

@antihax@bvwells@grokify@kemokemo@bkabrda

A similar implementation has been done for Python and was merged to master.

[jimschubert]

LGTM!

[jimschubert]

I've merged the linked pre-req PRs. This should be good to merge after master builds pass.

[sebastien-rosset]

This is adding a new "HTTP signature" security schemes (https://datatracker.ietf.org/doc/draft-cavage-http-signatures/). HTTP signatures is still a IETF draft, and hopefully it will become an official RFC this year. On one hand one may argue it shouldn’t be added because it’s still a draft, but on the other hand it is already being used by multiple products, so there may be benefits to support it. It is possible multiple organizations are independently adding the same security scheme.

Ideally one way to address the problem would be to make it possible to add new security schemes (such as HTTP signature) without being required to fork the OpenAPITools repo. But given the current code structure, it’s not clear to me how this could be achieved. Adding new security schemes involves surgery in multiple locations (Java codegen, templates, mustache tags).

I raised this point in Slack before opening the PR.

This PR depends on #4993 and #4934

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[sebastien-rosset]

There is a dependency on golang 1.10.
What is the version of golang being used to build the "go" and "go-experimental" artifacts? It looks like it is a version < 1.10. Where is this specified? What is the rule for upgrading the go version? For example, how do you decide whether it's ok to upgrade to 1.13.6? This PR uses strings.Builder, but that is defined in 1.10 and above. Should I write code to do the equivalent of strings.Builder? Or submit another PR to upgrade the version of golang?

Update: golang 1.10 dependency is no longer needed. I am using bytes.Buffer. The circleCI build environment should be improved to give better control over the version of golang, but that should be done in a separate PR.

[jimschubert]

I kicked off CircleCI again, since it failed but at quick glance it seemed unrelated to work in this PR.

[sebastien-rosset]

I just learned some people save their private key with file extensions other than ".pem", so I am going to relax the validation of the private key suffix.

[sebastien-rosset]

@antihax@bvwells@grokify@kemokemo@bkabrda

A similar implementation has been done for Python and was merged to master.

[jimschubert]

LGTM!

[jimschubert]

I've merged the linked pre-req PRs. This should be good to merge after master builds pass.