# My first elm package: elm-hmac-sha1

**URL:** <https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798>\
**Category:** Request Feedback\
**Created:** [December 21, 2018, 4:24pm UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798 "2018-12-21T16:24:46Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![rlopezc](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rlopezc/32/5018_2.png) [@rlopezc](https://discourse.elm-lang.org/u/rlopezc)\
**Post date:** [December 21, 2018, 4:24pm UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/1 "2018-12-21T16:24:47Z")

</div>

Hello everyone. I’m following the guidelines and I wanted to ask you what do you think about this before publishing it.

Here is the repo: [https://github.com/romariolopezc/elm-hmac-sha1](https://github.com/romariolopezc/elm-hmac-sha1)  
And here is the documentation: [https://package.elm-lang.org/packages/romariolopezc/elm-hmac-sha1/latest/](https://package.elm-lang.org/packages/romariolopezc/elm-hmac-sha1/latest/)

- What is the concrete problem you want to solve?  
HMAC-SHA1 computation

- What would it mean for your API to be a success?  
Other people using it

- Who has this problem? What do they want from an API?  
–

- What specific things are needed to solve that problem?  
Use SHA1 as the hash function for the HMAC

- Have other people worked on this problem? What lessons can be learned from them? Are there specific weaknesses you want to avoid?  
–

Thanks to ktonon, I reused the HMAC logic from it’s package (elm-crypto). I first asked if he was going to add sha-1 to the package ([https://github.com/ktonon/elm-crypto/issues/3](https://github.com/ktonon/elm-crypto/issues/3)), and he pointed me to a sha-1 implementation, so I just connected both.

---

<div class="post-metadata">

**Author:** ![dmy](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/dmy/32/702_2.png) [@dmy](https://discourse.elm-lang.org/u/dmy)\
**Post date:** [December 22, 2018, 7:49am UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/2 "2018-12-22T07:49:56Z")

</div>

Three quick thoughts:

1. Maybe add a more descriptive [`README`](https://elm-doc-preview.netlify.com/?repo=romariolopezc%2Felm-hmac-sha1) as this is usually the first page that users see:
  - What is HMAC-SHA1 (with a link)?
  - When is it useful or usually used, some examples?
  - A small code example
  - What is the difference between SHA1 and HMAC-SHA1 as this may be confusing?

2. Will people need to be able to run it on [Bytes](https://package.elm-lang.org/packages/elm/bytes/latest/Bytes#Bytes)? Also maybe returning the digest as Bytes? I’m not sure, just asking. Also your `toBytes` function name may be ambiguous because of that.
3. In `toBytes` example, shouldn’t it be a `==`? Maybe use [elm-verify-examples](https://github.com/stoeffel/elm-verify-examples) for consistency?

---

<div class="post-metadata">

**Author:** ![rlopezc](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rlopezc/32/5018_2.png) [@rlopezc](https://discourse.elm-lang.org/u/rlopezc)\
**Post date:** [December 23, 2018, 6:42pm UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/3 "2018-12-23T18:42:10Z")

</div>

Thanks for the feedback dmy. I improved the package.

Update:

- Using an opaque type with `elm/bytes` representation
- Added `README`
- Improved documentation
- Using `elm-verify-examples` and `elm-test`
- Everything returns a `Result` for consistency

---

<div class="post-metadata">

**Author:** ![rlopezc](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rlopezc/32/5018_2.png) [@rlopezc](https://discourse.elm-lang.org/u/rlopezc)\
**Post date:** [December 24, 2018, 3:02am UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/4 "2018-12-24T03:02:03Z")

</div>

I published the Package: [https://package.elm-lang.org/packages/romariolopezc/elm-hmac-sha1/latest/](https://package.elm-lang.org/packages/romariolopezc/elm-hmac-sha1/latest/) 😃

---

<div class="post-metadata">

**Author:** ![luke](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/luke/32/709_2.png) [@luke](https://discourse.elm-lang.org/u/luke)\
**Post date:** [December 25, 2018, 6:01am UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/5 "2018-12-25T06:01:03Z")

</div>

I think the API is very nice! I can offer some feedback here specifically on the feature this package provides:

- Packages that implement cryptographic algorithms should denote in the README whether they have been peer reviewed. ktonon/elm-crypto’s README includes such a section at the end.
- SHA-1 is not considered cryptographically strong, and the strength of an HMAC depends in part on the strength of the hash. So the README should denote this as well to ensure people only use it for things like interoperating with systems that still use HMAC-SHA1 and not for implementing new integrity and authenticity checking in their own software.

---

<div class="post-metadata">

**Author:** ![rlopezc](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rlopezc/32/5018_2.png) [@rlopezc](https://discourse.elm-lang.org/u/rlopezc)\
**Post date:** [December 26, 2018, 7:17pm UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/6 "2018-12-26T19:17:13Z")

</div>

Thanks for the feedback Luke! I updated the README with more information.

I only have doubts about the versioning. Why if I change just the README (no code), elm needs to bump the version?

Changing README: 1.0.1 -\> 1.0.2

---

<div class="post-metadata">

**Author:** ![luke](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/luke/32/709_2.png) [@luke](https://discourse.elm-lang.org/u/luke)\
**Post date:** [December 26, 2018, 9:22pm UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/7 "2018-12-26T21:22:55Z")

</div>

Thank you! Published Elm packages are linked to a specific git commit. The package website loads everything, including the README, from the tree at the commit for a particular version.

---

<div class="post-metadata">

**Author:** ![tzemanovic](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/tzemanovic/32/1026_2.png) [@tzemanovic](https://discourse.elm-lang.org/u/tzemanovic)\
**Post date:** [December 30, 2018, 8:09am UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/8 "2018-12-30T08:09:51Z")

</div>

Hi,

Thanks for this nice package!

I have some feedback. If I understand it correctly, your encoder `listToBytes` and decoder `bytesToMaybeList` are almost inverses of each other. If you were to store the digest in `type Digest = Digest (List Int)`, your `toBytes` and `toIntList` would have clearer API as you could return the representation directly without the Result wrapping.

---

<div class="post-metadata">

**Author:** ![rlopezc](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rlopezc/32/5018_2.png) [@rlopezc](https://discourse.elm-lang.org/u/rlopezc)\
**Post date:** [December 31, 2018, 5:42am UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/9 "2018-12-31T05:42:54Z")

</div>

Ah yes that is clearer, and it only converts the list to bytes in that `toBytes` function instead of each of the representation _to_\* functions.

I have doubts on the Result wrapping. Is clear that I don’t need to wrap it but I wanted to standardize the functions return Types, all returning `Result String Representation`, what do you think? @tzemanovic

I saw the PR thanks for that!

---

<div class="post-metadata">

**Author:** ![tzemanovic](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/tzemanovic/32/1026_2.png) [@tzemanovic](https://discourse.elm-lang.org/u/tzemanovic)\
**Post date:** [December 31, 2018, 6:19am UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/10 "2018-12-31T06:19:36Z")

</div>

I think baseX encoding (but not decoding) should be possible to implement in a way that it can never fail. I.e. it should be able to encode any arbitrary byte sequence.

It seems to me that in the upstream library elm-coder the encoding can fail because the implementation relies on List.Extra.getAt, which can fail when you try to access invalid index. If that’s possible to improve then all your toX can also avoid the Result wrapper.

Personally, even if that’s not technically correct or possible, I think in this case it would be preferable to have clearer API on those two functions rather than making them all consistent. They would most likely be consumed in different ways, so it doesn’t give you much benefit to have standard looking outputs (one is List Int, the other is Bytes and the other two are String)

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)\
**Post date:** [January 10, 2019, 6:19am UTC](https://discourse.elm-lang.org/t/my-first-elm-package-elm-hmac-sha1/2798/11 "2019-01-10T06:19:44Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.