157 lines
6.3 KiB
Text
157 lines
6.3 KiB
Text
----- BEGIN CREV PROOF -----
|
|
kind: package review
|
|
version: -1
|
|
date: "2022-06-21T12:11:23.522880184+02:00"
|
|
from:
|
|
id-type: crev
|
|
id: YdnEoYtqvbBGv0hhENLDUYmc3tNfm5V5NIG5hCovHyM
|
|
url: "https://git.jcg.re/jcgruenhage/crev-proofs.git"
|
|
package:
|
|
source: "https://crates.io"
|
|
name: tower-default-headers
|
|
version: 0.1.1
|
|
revision: d83869328a60d788e2d8463f492e7bc6d11e0073
|
|
digest: 2IiUJ8ehwjZmsNM9lWRZppj1acGDt8X1uyPZw3o5yDM
|
|
review:
|
|
thoroughness: high
|
|
understanding: high
|
|
rating: positive
|
|
comment: |-
|
|
Useful middleware, solid implementation. I'm honestly surprised that I
|
|
haven't found any alternatives, considering this is such a basic feature.
|
|
----- SIGN CREV PROOF -----
|
|
mJagAUfgDd8cusPe6ha009XxnQ2fCLzHl17T3gLpebo1RgIWmW6b41oezwkxbQeRh2i4Py7m1olDvu5fUSPsBg
|
|
----- END CREV PROOF -----
|
|
|
|
----- BEGIN CREV PROOF -----
|
|
kind: package review
|
|
version: -1
|
|
date: "2022-06-27T22:44:05.352091075+02:00"
|
|
from:
|
|
id-type: crev
|
|
id: YdnEoYtqvbBGv0hhENLDUYmc3tNfm5V5NIG5hCovHyM
|
|
url: "https://git.jcg.re/jcgruenhage/crev-proofs.git"
|
|
package:
|
|
source: "https://crates.io"
|
|
name: yap
|
|
version: 0.7.2
|
|
revision: 6ee4dfc176a5690063e391603b2b6ad2bd5b2514
|
|
digest: K5Fu1zb_agTCEM2nYx2SyUDzBPRJ4EAFi8aK1eubGMM
|
|
review:
|
|
thoroughness: high
|
|
understanding: high
|
|
rating: positive
|
|
alternatives:
|
|
- source: "https://crates.io"
|
|
name: nom
|
|
comment: |-
|
|
Simple enough parser combinator library that comes with most of the bells and
|
|
whistles I was looking for. I've noticed a few minor things that could use
|
|
improving, but nothing critical.
|
|
|
|
First of all, why did I review this? I implemented parsing a specific HTTP
|
|
auth header credential, which is non-trivial to do with just string splitting.
|
|
I had gathered some experience with `yap` during last years Advent of Code,
|
|
and I'm relatively happy with the implementation now. The only thing I was
|
|
missing is something like `Tokens::optional` that was based on `Result`
|
|
instead of `Option`. I'll make sure to contribute that later though.
|
|
|
|
As for problems I've found while reviewing this crate:
|
|
|
|
- There's one sound use of unsafe, that could probably be avoided, just for
|
|
good measure. It's about going from a `str` to the next `char`. It
|
|
increases a counter by one, and then by another one until it's at a char
|
|
boundary. This is explicitly checked before it then does
|
|
`str::get_unchecked`, which is the unsafe call. It seems sound to me, but
|
|
without tests this isn't a great look.
|
|
|
|
- The formatting is a bit off in some places. A few extra spaces, nothing
|
|
big, just made reviewing a bit more of a chore.
|
|
|
|
- The `logos` dev-dependency doesn't seem to be used anywhere. As `logos` is
|
|
quite wide-spread, it being included in yap is not much of a supply chain
|
|
safety loss, but when it's not used it should probably be dropped anyway.
|
|
|
|
Things I specifically liked:
|
|
|
|
- The documentation is amazing. Every single thing one could hope for has a
|
|
doc comment, and the documentation really goes above and beyond to
|
|
demonstrate how yap can be used.
|
|
|
|
- Leveraging iterators was a very good choice. Using `yap` feels super
|
|
natural, and even without any prior parser-combinator experience, I was
|
|
able to quickly get started. Not using regular expressions and string
|
|
splitting feels really good.
|
|
|
|
In general, I'm extremely happy with yap, and even happier now that I've done
|
|
my due diligence with regards to supply chain security. Thanks to the authors.
|
|
----- SIGN CREV PROOF -----
|
|
wWTVLbr4D3hgMVVz8g7Q5GQdiSXO-_FlbVdQ0rWJ7jMNValXnZGLnDNPiM5gZFx9-JCw95pmZOpRaHMjBlrnDw
|
|
----- END CREV PROOF -----
|
|
|
|
----- BEGIN CREV PROOF -----
|
|
kind: package review
|
|
version: -1
|
|
date: "2022-06-27T23:46:01.955622651+02:00"
|
|
from:
|
|
id-type: crev
|
|
id: YdnEoYtqvbBGv0hhENLDUYmc3tNfm5V5NIG5hCovHyM
|
|
url: "https://git.jcg.re/jcgruenhage/crev-proofs.git"
|
|
package:
|
|
source: "https://crates.io"
|
|
name: yap
|
|
version: 0.7.2
|
|
revision: 6ee4dfc176a5690063e391603b2b6ad2bd5b2514
|
|
digest: K5Fu1zb_agTCEM2nYx2SyUDzBPRJ4EAFi8aK1eubGMM
|
|
review:
|
|
thoroughness: high
|
|
understanding: high
|
|
rating: positive
|
|
alternatives:
|
|
- source: "https://crates.io"
|
|
name: nom
|
|
comment: |-
|
|
Simple enough parser combinator library that comes with most of the bells and
|
|
whistles I was looking for. I've noticed a few minor things that could use
|
|
improving, but nothing critical.
|
|
|
|
First of all, why did I review this? I implemented parsing a specific HTTP
|
|
auth header credential, which is non-trivial to do with just string splitting.
|
|
I had gathered some experience with `yap` during last years Advent of Code,
|
|
and I'm relatively happy with the implementation now. The only thing I was
|
|
missing is something like `Tokens::optional` that was based on `Result`
|
|
instead of `Option`. I'll make sure to contribute that later though.
|
|
|
|
As for problems I've found while reviewing this crate:
|
|
|
|
- There's one sound use of unsafe, that could probably be avoided, just for
|
|
good measure. It's about going from a `str` to the next `char`. It
|
|
increases a counter by one, and then by another one until it's at a char
|
|
boundary. This is explicitly checked before it then does
|
|
`str::get_unchecked`, which is the unsafe call. It seems sound to me, but
|
|
without tests this isn't a great look.
|
|
|
|
- The formatting is a bit off in some places. A few extra spaces, nothing
|
|
big, just made reviewing a bit more of a chore.
|
|
|
|
- A previous version of this review claimed that the `logos` dev-dependency
|
|
wasn't used anywhere. That's true for the releases on crates.io, but the
|
|
repository contains examples, where `logos` is actually used.
|
|
|
|
Things I specifically liked:
|
|
|
|
- The documentation is amazing. Every single thing one could hope for has a
|
|
doc comment, and the documentation really goes above and beyond to
|
|
demonstrate how yap can be used.
|
|
|
|
- Leveraging iterators was a very good choice. Using `yap` feels super
|
|
natural, and even without any prior parser-combinator experience, I was
|
|
able to quickly get started. Not using regular expressions and string
|
|
splitting feels really good.
|
|
|
|
In general, I'm extremely happy with yap, and even happier now that I've done
|
|
my due diligence with regards to supply chain security. Thanks to the authors.
|
|
----- SIGN CREV PROOF -----
|
|
Zjv7bZRcXGnY0bHWTqtrHnO02n07ztgRgEEG8gjk7RYtt2KZC-oYNzRVHGYwAvicP31CfXaxCT38RNl5Z4WIAQ
|
|
----- END CREV PROOF -----
|
|
|