1. 11 Jul, 2016 1 commit
  2. 26 Apr, 2016 1 commit
  3. 15 Apr, 2016 1 commit
    • Drew's avatar
      Update to swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a · 42da1058
      Drew authored
      I am annoyed.
      
      * inout (new for Swift 3 I guess...).  This produces warnings everywhere
        in Swift 2.2, which we can't very well fix.
      * More random foundation changes
      * The first parameter now has a label.  I swear we change this fucking
        behavior every fucking release
      
      I would *really* like to kill our foundation dependency.
      42da1058
  4. 30 Mar, 2016 1 commit
    • Drew's avatar
      Separate keys out to different APIs · 1c719b75
      Drew authored
      For some time now, there have been various issues with the key API.  It
      is confusing (resolve #14), and in some cases dangerous (resolve #6).
      
      The class `Key` is ambiguous as to whether or not it is a public or
      private key.
      
      What's more, keys are not interchangeable, and it is somewhere between
      stupid and dangerous to pass one type of key to a function that expects
      another.  We already have so-called *provenance* issues where public
      keys sometimes contain and other times don't contain a reference to some
      secret key (depending on whether they were generated togehter), and this
      gets worse when you want to implement digital signature verification for
      which public keys cannot be derived from private keys due to NaCl
      internal implementation details.
      
      To resolve this, the API formerly known as `Key` is now deprecated.
      This breaks probably all programs, but the migration path should be
      fairly minor (non-semver FTW!)
      
      Internally, `Key` is now `KeyImpl` and implements all the side-channel
      attack logic as previously.
      
      New public protocols `PublicKey` and `SecretKey` expose external API
      surface that was previously available NaOH-wide.  (One notable exception
      are the constructors, you need to know what you're constructing in order
      to make one, so those are key-type-specific).
      
      Function parameters now take an appropriate particular key type, which
      are implemented as structs.  However, the implementation is not copy-on-
      write for the private key data, which continues to be guarded against
      side-channel attacks.
      
      For applications, the primary aspects of the migration are:
      
      * Use a specific key type, instead of `Key`:
        try [CryptoBoxSecretKey, CryptoSecretBoxSecretKey, ChaCha20SecretKey],
        or check the parameter type of the function you're calling.
      * If no specific type is appropriate, try `SecretKey`.
      * Consider replacing custom file logic that references
        `humanReadableString` with `saveToFile`
      * Custom key types can no longer be created; consider using typealiases
        or file a bug
      1c719b75
  5. 19 Mar, 2016 1 commit
    • Drew's avatar
      Update for Swift 3 syntax · 80aa65f3
      Drew authored
      We now support Swift 3 syntax, and maintain compatibility
      with swift 2.2 and 2.1.  #15 is filed to drop Swift 2.1 support and #16 to drop Swift 2.2 support.
      80aa65f3
  6. 15 Feb, 2016 3 commits
  7. 06 Feb, 2016 1 commit
  8. 02 Feb, 2016 2 commits
  9. 28 Jan, 2016 2 commits
  10. 21 Jan, 2016 3 commits
  11. 19 Jan, 2016 1 commit