# and now when you run `aliasname` completion will make
# suggestions as it did for `origcommand`.
$ aliasname <tab>
completion firstcommand secondcommand
```
The name of the completer block variable is of the form `$__<programName>CompleterBlock` where every `-` and `:` in the program name have been replaced with `_`, to respect powershell naming syntax.
If you have different flags that must be provided together (e.g. if they provide the `--username` flag they MUST provide the `--password` flag as well) then
If you have different flags that must be provided together (e.g. if they provide the `--username` flag they MUST provide the `--password` flag as well) then
Cobra can enforce that requirement:
Cobra can enforce that requirement:
```go
```go
rootCmd.Flags().StringVarP(&u, "username", "u", "", "Username (required if password is set)")
rootCmd.Flags().StringVarP(&u, "username", "u", "", "Username (required if password is set)")
rootCmd.Flags().StringVarP(&pw, "password", "p", "", "Password (required if username is set)")
rootCmd.Flags().StringVarP(&pw, "password", "p", "", "Password (required if username is set)")
You can also prevent different flags from being provided together if they represent mutually
You can also prevent different flags from being provided together if they represent mutually
exclusive options such as specifying an output format as either `--json` or `--yaml` but never both:
exclusive options such as specifying an output format as either `--json` or `--yaml` but never both:
```go
```go
rootCmd.Flags().BoolVar(&u, "json", false, "Output in JSON")
rootCmd.Flags().BoolVar(&u, "json", false, "Output in JSON")
@ -327,29 +327,47 @@ In both of these cases:
## Positional and Custom Arguments
## Positional and Custom Arguments
Validation of positional arguments can be specified using the `Args` field of `Command`.
Validation of positional arguments can be specified using the `Args` field of `Command`.
The following validators are built in:
- Number of arguments:
- `NoArgs` - report an error if there are any positional args.
- `ArbitraryArgs` - accept any number of args.
- `MinimumNArgs(int)` - report an error if less than N positional args are provided.
- `MaximumNArgs(int)` - report an error if more than N positional args are provided.
- `ExactArgs(int)` - report an error if there are not exactly N positional args.
- `RangeArgs(min, max)` - report an error if the number of args is not between `min` and `max`.
- Content of the arguments:
- `OnlyValidArgs` - report an error if there are any positional args not specified in the `ValidArgs` field of `Command`, which can optionally be set to a list of valid values for positional args.
If `Args` is undefined or `nil`, it defaults to `ArbitraryArgs`.
If `Args` is undefined or `nil`, it defaults to `ArbitraryArgs`.
The following validators are built in:
Moreover, `MatchAll(pargs ...PositionalArgs)` enables combining existing checks with arbitrary other checks.
For instance, if you want to report an error if there are not exactly N positional args OR if there are any positional
args that are not in the `ValidArgs` field of `Command`, you can call `MatchAll` on `ExactArgs` and `OnlyValidArgs`, as
shown below:
- `NoArgs` - the command will report an error if there are any positional args.
```go
- `ArbitraryArgs` - the command will accept any args.
var cmd = &cobra.Command{
- `OnlyValidArgs` - the command will report an error if there are any positional args that are not in the `ValidArgs` field of `Command`.
Short: "hello",
- `MinimumNArgs(int)` - the command will report an error if there are not at least N positional args.
Args: MatchAll(ExactArgs(2), OnlyValidArgs),
- `MaximumNArgs(int)` - the command will report an error if there are more than N positional args.
Run: func(cmd *cobra.Command, args []string) {
- `ExactArgs(int)` - the command will report an error if there are not exactly N positional args.
fmt.Println("Hello, World!")
- `ExactValidArgs(int)` - the command will report an error if there are not exactly N positional args OR if there are any positional args that are not in the `ValidArgs` field of `Command`
},
- `RangeArgs(min, max)` - the command will report an error if the number of args is not between the minimum and maximum number of expected args.
}
- `MatchAll(pargs ...PositionalArgs)` - enables combining existing checks with arbitrary other checks (e.g. you want to check the ExactArgs length along with other qualities).
```
An example of setting the custom validator:
It is possible to set any custom validator that satisfies `func(cmd *cobra.Command, args []string) error`.
// Optionally run one of the validators provided by cobra
return errors.New("requires a color argument")
if err := cobra.MinimumNArgs(1)(cmd, args); err != nil {
return err
}
}
// Run the custom validation logic
if myapp.IsValidColor(args[0]) {
if myapp.IsValidColor(args[0]) {
return nil
return nil
}
}
@ -444,37 +462,46 @@ create' is called. Every command will automatically have the '--help' flag adde
The following output is automatically generated by Cobra. Nothing beyond the
The following output is automatically generated by Cobra. Nothing beyond the
command and flag definitions are needed.
command and flag definitions are needed.
$ cobra help
$ cobra-cli help
Cobra is a CLI library for Go that empowers applications.
Cobra is a CLI library for Go that empowers applications.
This application is a tool to generate the needed files
This application is a tool to generate the needed files
to quickly create a Cobra application.
to quickly create a Cobra application.
Usage:
Usage:
cobra [command]
cobra-cli [command]
Available Commands:
Available Commands:
add Add a command to a Cobra Application
add Add a command to a Cobra Application
completion Generate the autocompletion script for the specified shell
help Help about any command
help Help about any command
init Initialize a Cobra Application
init Initialize a Cobra Application
Flags:
Flags:
-a, --author string author name for copyright attribution (default "YOUR NAME")
-a, --author string author name for copyright attribution (default "YOUR NAME")
--config string config file (default is $HOME/.cobra.yaml)
--config string config file (default is $HOME/.cobra.yaml)
-h, --help help for cobra
-h, --help help for cobra-cli
-l, --license string name of license for the project
-l, --license string name of license for the project
--viper use Viper for configuration (default true)
--viper use Viper for configuration
Use "cobra [command] --help" for more information about a command.
Use "cobra-cli [command] --help" for more information about a command.
Help is just a command like any other. There is no special logic or behavior
Help is just a command like any other. There is no special logic or behavior
around it. In fact, you can provide your own if you want.
around it. In fact, you can provide your own if you want.
### Grouping commands in help
Cobra supports grouping of available commands in the help output. To group commands, each group must be explicitly
defined using `AddGroup()` on the parent command. Then a subcommand can be added to a group using the `GroupID` element
of that subcommand. The groups will appear in the help output in the same order as they are defined using different
calls to `AddGroup()`. If you use the generated `help` or `completion` commands, you can set their group ids using
`SetHelpCommandGroupId()` and `SetCompletionCommandGroupId()` on the root command, respectively.
### Defining your own help
### Defining your own help
You can provide your own Help command or your own template for the default command to use
You can provide your own Help command or your own template for the default command to use
with following functions:
with the following functions:
```go
```go
cmd.SetHelpCommand(cmd *Command)
cmd.SetHelpCommand(cmd *Command)
@ -493,22 +520,23 @@ showing the user the 'usage'.
You may recognize this from the help above. That's because the default help
You may recognize this from the help above. That's because the default help
embeds the usage as part of its output.
embeds the usage as part of its output.
$ cobra --invalid
$ cobra-cli --invalid
Error: unknown flag: --invalid
Error: unknown flag: --invalid
Usage:
Usage:
cobra [command]
cobra-cli [command]
Available Commands:
Available Commands:
add Add a command to a Cobra Application
add Add a command to a Cobra Application
completion Generate the autocompletion script for the specified shell
help Help about any command
help Help about any command
init Initialize a Cobra Application
init Initialize a Cobra Application
Flags:
Flags:
-a, --author string author name for copyright attribution (default "YOUR NAME")
-a, --author string author name for copyright attribution (default "YOUR NAME")
--config string config file (default is $HOME/.cobra.yaml)
--config string config file (default is $HOME/.cobra.yaml)
-h, --help help for cobra
-h, --help help for cobra-cli
-l, --license string name of license for the project
-l, --license string name of license for the project
--viper use Viper for configuration (default true)
--viper use Viper for configuration
Use "cobra [command] --help" for more information about a command.
Use "cobra [command] --help" for more information about a command.
@ -627,7 +655,7 @@ Did you mean this?
Run 'hugo --help' for usage.
Run 'hugo --help' for usage.
```
```
Suggestions are automatic based on every subcommand registered and use an implementation of [Levenshtein distance](https://en.wikipedia.org/wiki/Levenshtein_distance). Every registered command that matches a minimum distance of 2 (ignoring case) will be displayed as a suggestion.
Suggestions are automatically generated based on existing subcommands and use an implementation of [Levenshtein distance](https://en.wikipedia.org/wiki/Levenshtein_distance). Every registered command that matches a minimum distance of 2 (ignoring case) will be displayed as a suggestion.
If you need to disable suggestions or tweak the string distance in your command, use:
If you need to disable suggestions or tweak the string distance in your command, use:
@ -641,7 +669,8 @@ or
command.SuggestionsMinimumDistance = 1
command.SuggestionsMinimumDistance = 1
```
```
You can also explicitly set names for which a given command will be suggested using the `SuggestFor` attribute. This allows suggestions for strings that are not close in terms of string distance, but makes sense in your set of commands and for some which you don't want aliases. Example:
You can also explicitly set names for which a given command will be suggested using the `SuggestFor` attribute. This allows suggestions for strings that are not close in terms of string distance, but make sense in your set of commands but for which
+ Fixed bug where CLI requested admin privileges for all metadata operations, including listing targets on a repo [#1315](https://github.com/theupdateframework/notary/pull/1315)
+ Fixed bug where CLI requested admin privileges for all metadata operations, including listing targets on a repo [#1315](https://github.com/theupdateframework/notary/pull/1315)
+ Prevented notary signer from being dumpable or ptraceable in Linux, except in debug mode [#1327](https://github.com/theupdateframework/notary/pull/1327)
+ Prevented notary signer from being dumpable or being ptraced in Linux, except in debug mode [#1327](https://github.com/theupdateframework/notary/pull/1327)
+ Bumped JWT dependency to fix potential Invalid Curve Attack on NIST curves within ECDH key management [#1334](https://github.com/theupdateframework/notary/pull/1334)
+ Bumped JWT dependency to fix potential Invalid Curve Attack on NIST curves within ECDH key management [#1334](https://github.com/theupdateframework/notary/pull/1334)
+ If the home directory cannot be found, log a warning instead of erroring out [#1318](https://github.com/theupdateframework/notary/pull/1318)
+ If the home directory cannot be found, log a warning instead of erroring out [#1318](https://github.com/theupdateframework/notary/pull/1318)
+ Bumped go version and various dependencies [#1323](https://github.com/theupdateframework/notary/pull/1323) [#1332](https://github.com/theupdateframework/notary/pull/1332) [#1335](https://github.com/theupdateframework/notary/pull/1335) [#1336](https://github.com/theupdateframework/notary/pull/1336)
+ Bumped go version and various dependencies [#1323](https://github.com/theupdateframework/notary/pull/1323) [#1332](https://github.com/theupdateframework/notary/pull/1332) [#1335](https://github.com/theupdateframework/notary/pull/1335) [#1336](https://github.com/theupdateframework/notary/pull/1336)
As contributors and maintainers of this project, and in the interest of fostering
an open and welcoming community, we pledge to respect all people who contribute
through reporting issues, posting feature requests, updating documentation,
submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for
everyone, regardless of level of experience, gender, gender identity and expression,
sexual orientation, disability, personal appearance, body size, race, ethnicity, age,
religion, or nationality.
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
* Public or private harassment
* Publishing other's private information, such as physical or electronic addresses,
without explicit permission
* Other unethical or unprofessional conduct.
Project maintainers have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are not
aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers
commit themselves to fairly and consistently applying these principles to every aspect
of managing this project. Project maintainers who do not follow or enforce the Code of
Conduct may be permanently removed from the project team.
This code of conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a CNCF project maintainer, Sarah Novotny <sarahnovotny@google.com>, and/or Dan Kohn <dan@linuxfoundation.org>.
This Code of Conduct is adapted from the Contributor Covenant
(https://contributor-covenant.org), version 1.2.0, available at
https://contributor-covenant.org/version/1/2/0/
### CNCF Events Code of Conduct
CNCF events are governed by the Linux Foundation [Code of Conduct](https://events.linuxfoundation.org/events/cloudnativecon/attend/code-of-conduct) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents.
&& go get github.com/golang/lint/golint github.com/fzipp/gocyclo github.com/client9/misspell/cmd/misspell github.com/gordonklaus/ineffassign github.com/HewlettPackard/gas
The following document outlines Notary project governance.
## The Notary Project
The Notary project consists of several repositories known as subprojects that enable community cohorts to experiment and implement solutions across the scope of the project.
## Maintainers Structure
There are two types of maintainers in the Notary project organized hierarchically. Notary org maintainers oversee the overall project and its health. Subproject maintainers focus on a single codebase or a group of related codebases.
Changes in maintainership have to be announced via an [issue](https://github.com/notaryproject/notaryproject/issues/new).
### Maintainer Responsibility
Notary maintainers adhere to the requirements and responsibilities set forth in the respective [Notary Org Maintainers](#notary-org-maintainers) and [Subproject Maintainers](#subproject-maintainers). They further pledge the following:
* To act in the best interest of the project and subprojects at all times.
* To ensure that project and subproject development and direction is a function of community needs.
* To never take any action while hesitant that it is the right action to take.
* To fulfill the responsibilities outlined in this document and its dependents.
### Notary Org Maintainers
The [Notary Org maintainers](MAINTAINERS) are responsible for:
* Maintaining the mission, vision, values, and scope of the project
* Refining the governance and charter as needed
* Making project level decisions
* Resolving escalated project decisions when the subproject maintainers responsible are blocked
* Managing the Notary brand
* Controlling access to Notary assets such as source repositories, hosting, project calendars
* Deciding what subprojects are part of the Notary project
* Deciding on the creation of new subprojects
* Overseeing the resolution and disclosure of security issues
* Managing financial decisions related to the project
Changes to org maintainers use the following:
* Any subproject maintainer is eligible for a position as an org maintainer
* No one company or organization can employ a simple majority of the org maintainers
* An org maintainer may step down by submitting an [issue](https://github.com/notaryproject/notaryproject/issues/new) stating their intent and they will be moved to emeritus.
* Org maintainers MUST remain active on the project. If they are unresponsive for > 3 months they will lose org maintainership unless a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) of the other org maintainers agrees to extend the period to be greater than 3 months
* Any eligible person may stand as an org maintainer by opening a [PR](https://github.com/notaryproject/notaryproject/pulls).
* When a PR is opened the project maintainers may vote
* The voting period will be open for a minimum of three business days and will remain open until a super-majority of project maintainers has voted
* Only current org maintainers are eligible to vote via casting a single vote each via a -1/+1 comment on the nomination issue or approving in GitHub.
* Once a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) has been reached the maintainer elect must complete [onboarding](#onboarding-a-new-maintainer) prior to becoming an official Notary maintainer.
* Once the maintainer onboarding has been completed a pull request is made on the repo adding the new maintainer to the [MAINTAINERS](MAINTAINERS) file.
* When an org maintainer steps down, they become an emeritus maintainer
### Subproject Maintainers
Subproject maintainers are responsible for activities surrounding the development and release of content (eg. code, specifications, documentation) or the tasks needed to execute their subproject (e.g., community management) within the designated repository, or repositories associated with the subproject (e.g., community management). Technical decisions for code resides with the subproject maintainers unless there is a decision related to cross maintainer groups that cannot be resolved by those groups. Those cases can be escalated to the org maintainers.
Subprojects may be responsible for one or many repositories.
Subproject maintainers do not need to be software developers. No explicit role is placed upon them and they can be anyone appropriate for the work being produced. For example, if a repository is for documentation it would be appropriate for maintainers to be technical writers.
Changes to maintainers use the following:
* A subproject maintainer may step down by submitting an [issue](https://github.com/notaryproject/notaryproject/issues/new) stating their intent and they will be moved to emeritus.
* Maintainers MUST remain active. If they are unresponsive for > 6 months they will be automatically removed unless a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) of the other subproject maintainers agrees to extend the period to be greater than 6 months
* Potential new maintainers should be ongoing active participants in the project
* New maintainers can be added to a subproject by a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) vote of the existing subproject maintainers
* When a subproject has no maintainers the Notary org maintainers become responsible for it and may archive the subproject or find new maintainers
### Onboarding a New Maintainer
New Notary maintainers participate in an onboarding period during which they fulfill all code review and issue management responsibilities that are required for their role. The length of this onboarding period is variable, and is considered complete once both the existing maintainers and the candidate maintainer are comfortable with the candidate's competency in the responsibilities of maintainership. This process MUST be completed prior to the candidate being named an official Notary maintainer.
The onboarding period is intended to ensure that the to-be-appointed maintainer is able/willing to take on the time requirements, familiar with core logic and concepts, understands the overall system architecture and interactions that comprise it, and is able to work well with both the existing maintainers and the community.
## Decision Making at the Notary org level
When maintainers need to make decisions there are two ways decisions are made, unless described elsewhere.
The default decision making process is [lazy-consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus). This means that any decision is considered supported by the team making it as long as no one objects. Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will. In the case of security critical decisions more explicit consensus may be needed.
When a consensus cannot be found a maintainer can call for a [majority](https://en.wikipedia.org/wiki/Majority) vote on a decision.
Many of the day-to-day project maintenance can be done by a lazy consensus model. But the following items must be called to vote:
* Removing a maintainer for any reason other than inactivity (super majority)
* Changing the governance rules (this document) (super majority)
* Licensing and intellectual property changes (including new logos, wordmarks) (simple majority)
* Adding, archiving, or removing subprojects (simple majority)
* Utilizing Notary/CNCF money for anything CNCF deems "not cheap and easy" (simple majority)
New subprojects should be created (or added) with a well defined mission and goals, and significant changes should be voted on by both the subproject maintainers and the org maintainers.
Other decisions may, but do not need to be, called out and put up for decision via creating an [issue](https://github.com/notaryproject/notaryproject/issues/new) at any time and by anyone. By default, any decisions called to a vote will be for a _simple majority_ vote.
Meetings should be publically documented (Slack, CNCF calendar etc), and recorded and notes kept. Meetings should have a chair, this is a rotating role not restricted to maintainers.
## Code of Conduct
This Notary project has adopted the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
## Attributions
* This governance model was created using both the [SPIFFE](https://github.com/spiffe/spire/blob/main/MAINTAINERS.md) and [Helm](https://github.com/helm/community/blob/main/governance/governance.md) governance documents.
## DCO and Licenses
The following licenses and contributor agreements will be used for Notary projects:
* [Apache 2.0](https://opensource.org/licenses/Apache-2.0) for code
* [Developer Certificate of Origin](https://developercertificate.org/) for new contributions
This document lays out some basic rules and guidelines all maintainers are expected to follow.
Changes to the [Acceptance Criteria](#hard-acceptance-criteria-for-merging-a-pr) for merging PRs require a ceiling(two-thirds) supermajority from the maintainers.
Changes to the [Repo Guidelines](#repo-guidelines) require a simple majority.
## Hard Acceptance Criteria for merging a PR:
- 2 LGTMs are required when merging a PR
- If there is obviously still discussion going on in the PR, even with 2 LGTMs, let the discussion resolve before merging. If you’re not sure, reach out to the maintainers involved in the discussion.
- All checks must be green
- There are limited mitigating circumstances for this, like if the docs builds are just broken and that’s the only test failing.
- Adding or removing a check requires simple majority approval from the maintainers.
## Repo Guidelines:
- Consistency is vital to keep complexity low and understandable.
- Automate as much as possible (we don’t have guidelines about coding style for example because we’ve automated fmt, vet, lint, etc…).
- Try to keep PRs small and focussed (this is not always possible, i.e. builder refactor, storage refactor, etc… but a good target).
## Process for becoming a maintainer:
- Invitation is proposed by an existing maintainer.
- Ceiling(two-thirds) supermajority approval from existing maintainers (including vote of proposing maintainer) required to accept proposal.
- Newly approved maintainer submits PR adding themselves to the MAINTAINERS file.
- Existing maintainers publicly mark their approval on the PR.
- Existing maintainer updates repository permissions to grant write access to new maintainer.
- New maintainer merges their PR.
## Removing maintainers
It is preferrable that a maintainer gracefully removes themselves from the MAINTAINERS file if they are
aware they will no longer have the time or motivation to contribute to the project. Maintainers that
have been inactive in the repo for a period of at least one year should be contacted to ask if they
wish to be removed.
In the case that an inactive maintainer is unresponsive for any reason, a ceiling(two-thirds) supermajority
vote of the existing maintainers can be used to approve their removal from the MAINTAINERS file, and revoke
Notary aims to make the internet more secure by making it easy for people to
Notary aims to make the internet more secure by making it easy for people to
publish and verify content. We often rely on TLS to secure our communications
publish and verify content. We often rely on TLS to secure our communications
with a web server which is inherently flawed, as any compromise of the server
with a web server, which is inherently flawed, as any compromise of the server
enables malicious content to be substituted for the legitimate content.
enables malicious content to be substituted for the legitimate content.
With Notary, publishers can sign their content offline using keys kept highly
With Notary, publishers can sign their content offline using keys kept highly
@ -46,11 +46,16 @@ Notary is based on [The Update Framework](https://www.theupdateframework.com/),
## Security
## Security
Any security vulnerabilities can be reported to security@docker.com.
See Notary's [service architecture docs](docs/service_architecture.md#threat-model) for more information about our threat model, which details the varying survivability and severities for key compromise as well as mitigations.
See Notary's [service architecture docs](docs/service_architecture.md#threat-model) for more information about our threat model, which details the varying survivability and severities for key compromise as well as mitigations.
Notary's last security audit was on July 31, 2015 by NCC ([results](docs/resources/ncc_docker_notary_audit_2015_07_31.pdf)).
### Security Audits
Any security vulnerabilities can be reported to security@docker.com.
Notary has had two public security audits:
* [August 7, 2018 by Cure53](docs/resources/cure53_tuf_notary_audit_2018_08_07.pdf) covering TUF and Notary
* [July 31, 2015 by NCC](docs/resources/ncc_docker_notary_audit_2015_07_31.pdf) covering Notary
# Getting started with the Notary CLI
# Getting started with the Notary CLI
@ -65,7 +70,7 @@ For more advanced usage, see the
To use the CLI against a local Notary server rather than against Docker Hub:
To use the CLI against a local Notary server rather than against Docker Hub:
1. Ensure that you have [docker and docker-compose](http://docs.docker.com/compose/install/) installed.
1. Ensure that you have [docker and docker-compose](https://docs.docker.com/compose/install/) installed.
1. `git clone https://github.com/theupdateframework/notary.git` and from the cloned repository path,
1. `git clone https://github.com/theupdateframework/notary.git` and from the cloned repository path,
start up a local Notary server and signer and copy the config file and testing certs to your
start up a local Notary server and signer and copy the config file and testing certs to your
local Notary config directory:
local Notary config directory:
@ -88,6 +93,20 @@ URL is specified already in the configuration, file you copied.
You can also leave off the `-d ~/.docker/trust` argument if you do not care
You can also leave off the `-d ~/.docker/trust` argument if you do not care
to use `notary` with Docker images.
to use `notary` with Docker images.
## Upgrading dependencies
To prevent mistakes in vendoring the go modules a buildscript has been added to properly vendor the modules using the correct version of Go to mitigate differences in CI and development environment.
Following procedure should be executed to upgrade a dependency. Preferably keep dependency upgrades in a separate commit from your code changes.
```bash
go get -u github.com/spf13/viper
buildscripts/circle-validate-vendor.sh
git add .
git commit -m "Upgraded github.com/spf13/viper"
```
The `buildscripts/circle-validate-vendor.sh` runs `go mod tidy` and `go mod vendor` using the given version of Go to prevent differences if you are for example running on a different version of Go.
## Building Notary
## Building Notary
@ -97,25 +116,20 @@ branch and contains features for the next release.
Prerequisites:
Prerequisites:
- Go >= 1.7.1
* Go >= 1.12
- Fedora: `dnf install golang`
- libtool development headers installed
- Ubuntu: `apt-get install libltdl-dev`
- CentOS/RedHat: `yum install libtool-ltdl-devel`
- Fedora: `dnf install libtool-ltdl-devel`
- Mac OS ([Homebrew](http://brew.sh/)): `brew install libtool`
Set [```GOPATH```](https://golang.org/doc/code.html#GOPATH). Then, run:
Set [```GOPATH```](https://golang.org/doc/code.html#GOPATH). Then, run:
```bash
```bash
$ export GO111MODULE=on
$ go get github.com/theupdateframework/notary
$ go get github.com/theupdateframework/notary
# build with pcks11 support by default to support yubikey
# build with pkcs11 support by default to support yubikey
$ go install -tags pkcs11 github.com/theupdateframework/notary/cmd/notary
$ go install -tags pkcs11 github.com/theupdateframework/notary/cmd/notary
$ notary
$ notary
```
```
To build the server and signer, run `docker-compose build`.
To build the server and signer, run `docker-compose build`.
# STAGE - Build stage, calls make with given target argument (defaults to all make target)
#
FROM builder-base as builder
ARG target=all
ENV RUN_LOCAL=1
RUN mkdir -p /go/src
ADD . /go/src/
WORKDIR /go/src
RUN make $target
#
# STAGE - Test Build stage, calls make with given target argument (defaults to all make target). Valid for testing purposes only as tests require a specific (non-root) user access for directories read/write access.
&& go get github.com/golang/lint/golint github.com/fzipp/gocyclo github.com/client9/misspell/cmd/misspell github.com/gordonklaus/ineffassign github.com/HewlettPackard/gas
ENV GO111MODULE=on
# Configure the container for OSX cross compilation
ENV OSX_SDK MacOSX10.11.sdk
# Locked go cyclo on this commit as newer commits depend on Golang 1.16 io/fs
Sebastiaan van Stijn
3 years ago
committed by