1. 12 Nov, 2019 2 commits
    • Filippo Valsorda's avatar
      crypto/tls: refactor certificate and signature algorithm logic · ec732632
      Filippo Valsorda authored
      This refactors a lot of the certificate support logic to make it cleaner
      and reusable where possible. These changes will make the following CLs
      much simpler.
      
      In particular, the heavily overloaded pickSignatureAlgorithm is gone.
      That function used to cover both signing and verifying side, would work
      both for pre-signature_algorithms TLS 1.0/1.1 and TLS 1.2, and returned
      sigalg, type and hash.
      
      Now, TLS 1.0/1.1 and 1.2 are differentiated at the caller, as they have
      effectively completely different logic. TLS 1.0/1.1 simply use
      legacyTypeAndHashFromPublicKey as they employ a fixed hash function and
      signature algorithm for each public key type. TLS 1.2 is instead routed
      through selectSignatureScheme (on the signing side) or
      isSupportedSignatureAlgorithm (on the verifying side) and
      typeAndHashFromSignatureScheme, like TLS 1.3.
      
      On the signing side, signatureSchemesForCertificate was already version
      aware (for PKCS#1 v1.5 vs PSS support), so selectSignatureScheme just
      had to learn the Section 7.4.1.4.1 defaults for a missing
      signature_algorithms to replace pickSignatureAlgorithm.
      
      On the verifying side, pickSignatureAlgorithm was also checking the
      public key type, while isSupportedSignatureAlgorithm +
      typeAndHashFromSignatureScheme are not, but that check was redundant
      with the one in verifyHandshakeSignature.
      
      There should be no major change in behavior so far. A few minor changes
      came from the refactor: we now correctly require signature_algorithms in
      TLS 1.3 when using a certificate; we won't use Ed25519 in TLS 1.2 if the
      client didn't send signature_algorithms; and we don't send
      ec_points_format in the ServerHello (a compatibility measure) if we are
      not doing ECDHE anyway because there are no mutually supported curves.
      
      The tests also got simpler because they test simpler functions. The
      caller logic switching between TLS 1.0/1.1 and 1.2 is tested by the
      transcript tests.
      
      Updates #32426
      
      Change-Id: Ice9dcaea78d204718f661f8d60efdb408ba41577
      Reviewed-on: https://go-review.googlesource.com/c/go/+/205061Reviewed-by: default avatarKatie Hockman <katie@golang.org>
      ec732632
    • Dmitri Shuralyov's avatar
      go/doc: add NewFromFiles with support for classifying examples · 4faada90
      Dmitri Shuralyov authored
      This CL is based on work started by Joe Tsai in CL 94855.
      It's rebased on top of the latest master branch, and
      addresses various code review comments and findings
      from attempting to use the original CL in practice.
      
      The testing package documents a naming convention for examples
      so that documentation tools can associate them with:
      
      • a package (Example or Example_suffix)
      • a function F (ExampleF or ExampleF_suffix)
      • a type T (ExampleT or ExampleT_suffix)
      • a method T.M (ExampleT_M or ExampleT_M_suffix)
      
      This naming convention is in widespread use and enforced
      via existing go vet checks.
      
      This change adds first-class support for classifying examples
      to go/doc, the package responsible for computing package
      documentation from Go AST.
      
      There isn't a way to supply test files to New that works well.
      External test files may have a package name with "_test" suffix,
      so ast.NewPackage may end up using the wrong package name if given
      test files. A workaround is to add test files to *ast.Package.Files
      after it is returned from ast.NewPackage:
      
      	pkg, _ := ast.NewPackage(fset, goFiles, ...)
      	for name, f := range testGoFiles {
      		pkg.Files[name] = f
      	}
      	p := doc.New(pkg, ...)
      
      But that is not a good API.
      
      After nearly 8 years, a new entry-point is added to the go/doc
      package, the function NewFromFiles. It accepts a Go package in
      the form of a list of parsed Go files (including _test.go files)
      and an import path. The caller is responsible with filtering out
      files based on build constraints, as was the case before with New.
      NewFromFiles computes package documentation from .go files,
      extracts examples from _test.go files and classifies them.
      
      Examples fields are added to Package, Type, and Func. They are
      documented to only be populated with examples found in _test.go
      files provided to NewFromFiles.
      
      The new behavior is:
      
      1. NewFromFiles computes package documentation from provided
         parsed .go files. It extracts examples from _test.go files.
      2. It assigns each Example to corresponding Package, Type,
         or Func.
      3. It sets the Suffix field in each example to the suffix.
      4. Malformed examples are skipped.
      
      This change implements behavior that matches the current behavior
      of existing godoc-like tools, and will enable them to rely on the
      logic in go/doc instead of reimplementing it themselves.
      
      Fixes #23864
      
      Change-Id: Iae834f2ff92fbd1c93a9bb7c2bf47d619bee05cf
      Reviewed-on: https://go-review.googlesource.com/c/go/+/204830
      Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      4faada90
  2. 11 Nov, 2019 23 commits
  3. 10 Nov, 2019 8 commits
  4. 09 Nov, 2019 6 commits
  5. 08 Nov, 2019 1 commit
    • David Chase's avatar
      runtime: copy some functions from math/bits to runtime/internal/sys · 11da2b22
      David Chase authored
      CL 201765 activated calls from the runtime to functions in math/bits.
      When coverage and race detection were simultaneously enabled,
      this caused a crash when the covered+race-checked code in
      math/bits was called from the runtime before there was even a P.
      
      PS Win for gdlv in helping sort this out.
      
      TODO - next CL intrinsifies the new functions in
      runtime/internal/sys
      
      TODO/Would-be-nice - Ctz64 and TrailingZeros64 are the same
      function; 386.s is intrinsified; clean all that up.
      
      Fixes #35461.
      Updates #35112.
      
      Change-Id: I750a54dba493130ad3e68a06530ede7687d41e1d
      Reviewed-on: https://go-review.googlesource.com/c/go/+/206199Reviewed-by: default avatarMichael Knyszek <mknyszek@google.com>
      Run-TryBot: Michael Knyszek <mknyszek@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      11da2b22