1. 16 Aug, 2020 2 commits
    • SamwiseFilmore's avatar
      pkgar-keys: Update seckey + refactor passwd; Docs and cleanup · 1a0408dd
      SamwiseFilmore authored
      - SecKey took a lower-level approach for its 0.11 API, so I refactored
        passwords to include a new type to make sure everything gets zeroed.
      - Bunch of documentation work, I'm happy with the state of the rustdoc
        and error handling, at least enough to release 1.0 soon.
    • SamwiseFilmore's avatar
      pkgar-keys: Refactor Errors · faaf1c88
      SamwiseFilmore authored
      Fixed two little bugs:
      - Private key files now use 600 instead of 644
      - Fixed default key file paths
      Pulled in the same error deps as the main library,
      - UFE for easy pretty-printing of errors
      - thiserror for deriving std::error::Error for error types
      pkgar-keys now uses two error types, one that includes a file path for
      context and an ErrorKind for passing around internally and containing
      other error types. I'm still not happy with the sheer volume of
      boilerplate needed to create Error, so more work is needed, but error
      reporting is much better with these changes, and is probably more
      maintainable even given the boilerplate.
  2. 14 Aug, 2020 1 commit
  3. 04 Aug, 2020 2 commits
  4. 03 Aug, 2020 1 commit
    • SamwiseFilmore's avatar
      Small Error improvements; Passes tests · 48dac371
      SamwiseFilmore authored
      Everything appears to be functional. I assumed that two functions that
      were called the same thing with approximately the same contents had the
      same behavior... not a safe assumption to make. That function is now
      reimplemented, among with several other small fixes. I also added a call
      to `pkgar list` in the tests to make sure it doesn't panic or do
      something else equally dumb.
      I also added a dependency on UserFacingError... I'm not sure how much
      value it will add, but I can see it being more useful as pkgar matures
      and good error reporting becomes more critical. Many improvements on
      that front soon I hope.
      In terms of the refactoring that happened last commit: There are some
      critical issues with implementing PackageSrc as a trait, namely needing
      to call read_at (which should be considered expensive) in order to read
      the header, something that most of the functions have to do. read_at
      could conceiveably cross network boundaries in the future, so it's
      important not to call it unessesarily. More design work needs to be done
  5. 30 Jul, 2020 1 commit
    • SamwiseFilmore's avatar
      WIP: Refactor pkgar into two crates · 421aeae9
      SamwiseFilmore authored
      This compiles, but the tests fail due to an off by one or similar issue
      hiding someplace. Debugging is going to require a significant set of
      improvements to the error handling in the crate, the messages are crap
      I also added the thiserror crate to make generating error impls easier,
      so it should be fairly straightforward from that side of things to
      improve the errors. Note that thiserror isn't no_std right now, so it's
      only used in pkgar, pkgar_core implements all the froms without the help
      of a macro.
  6. 26 Jul, 2020 3 commits
  7. 25 Jul, 2020 2 commits
  8. 19 Jul, 2020 2 commits
  9. 18 Jul, 2020 3 commits
    • Jeremy Soller's avatar
      Merge branch 'libsodium' into 'master' · 060de420
      Jeremy Soller authored
      Port to libsodium
      See merge request !4
    • SamwiseFilmore's avatar
      Clean up old code/comments · 2871ad9a
      SamwiseFilmore authored
    • SamwiseFilmore's avatar
      Port to libsodium · 069b96b3
      SamwiseFilmore authored
      It looks like sodiumoxide only depends on std for serializing with
      serde, disabling default features should preserve no-std for the
      As I more or less don't know what I'm doing with crypto stuff, there's
      probably some bits of code in here that are super naive. Also it hasn't
      gone through much testing, so I don't know what the value is there
      I'd like to integrate `pkgar-keys` at some point (little project I've
      been working on to store keys for packaging and verification), but I'd
      appreciate some guidance on how those should be formatted. More
      discussion should probably happen in the repo:
  10. 14 Mar, 2020 1 commit
  11. 13 Mar, 2020 7 commits
  12. 12 Mar, 2020 3 commits
  13. 11 Mar, 2020 5 commits
  14. 25 Feb, 2020 1 commit
  15. 22 Feb, 2020 4 commits
  16. 21 Feb, 2020 2 commits