mirror of
https://github.com/agent-substrate/substrate.git
synced 2026-11-12 10:35:06 +08:00
Tim Hockin
a8d83ee1b5
This mostly eliminates the need to hand-write validation code. This PR is a long series of commits which add DV for most of Actor and all of Atespace. Here is a map to the commits: * The first few take a dep on a new Kubernetes tag, import the code into third_party, and apply a single patch. Because we have different Go modules for tools, I had to do it twice. When that patch lands, we can revert these commits, but that won't be until the 1.38 cycle in a few months. * The next commits slowly add DV support, so a human can review each of them in a reasonable amount of time. The emphasis is on great test cases. * I made a bad choice early on as to where to generate the code into, so I moved it. Rebasing on that was exceedingly hard, so I left it as a move. * This required changing update/go-generate -> update/codegen -- we need to get the ordering of tools right, which `go generate` does not guarantee. * Then I added a "middle" layer called "ServiceImpl" between the RPC and storage layers. This allows things like workflow to call the same business logic as the RPC layer, including validation. Lots of test fixes. * Then I finished the Create() and Update() paths for Actor. Those represent the "right" (or closest to) way to implement resources, and tests for validation. I strongly encourage reviewers to read it commit-by-commit. Rebasing this is VERY tedious, so the sooner it lands or dies completely, the better. Then we can start converting the rest. `./hack/run-tool.sh validation-gen --docs` will produce some docs on the tool and the available tags. @laoj2 @juli4n @EItanya @HavenXia @lalitc375 @yongruilin @jpbetz FYI
1.4 KiB
1.4 KiB
Security Policy
This policy outlines the commitment and practices of the go-openapi maintainers regarding security.
Supported Versions
| Version | Supported |
|---|---|
| O.x | ✅ |
Vulnerability checks in place
This repository uses automated vulnerability scans, at every merged commit and at least once a week.
We use:
Reports are centralized in github security reports and visible only to the maintainers.
Reporting a vulnerability
If you become aware of a security vulnerability that affects the current repository, please report it privately to the maintainers rather than opening a publicly visible GitHub issue.
Please follow the instructions provided by github to Privately report a security vulnerability.
Note
On Github, navigate to the project's "Security" tab then click on "Report a vulnerability".