https://github.com/softprops/zig-jwt
first release covers the basics but I plan to expand this to support a more complete set of features
#new JWT lib for zig
red dune
warm thunder
@red dune hey, sorry for the ping, any plan to maintain this for 0.14.0-dev? i'm willing to contribute a fix to get it working on 0.14.0-dev but i assume you'd want to put the 0.13.0 code on a different branch
red dune
I’d rather the reverse, 0.14 on a branch.
Zig historically has had no commitment to a predictable release schedule so 0.14 could land a month from now, a year from now, or last year. There is no commitment . so my commitment to projects is always the latest released version for stability purposes
It looks like 0.14 is past due with over a thousand issues to resolve so I don’t for see it being released soon https://github.com/ziglang/zig/milestone/20
versed saffron
I’d rather the reverse, 0.14 on a branch.
Zig historically has had no commitm...
Tbf, Andrew usually just moves all the issues to the next milestone when he wants to release
Most of the open issues in 14.0 were open issues for 12.0
Zig really should do an audit of all the open issues at some point
A lot of them haven't been active for years
red dune
More to the point zig has no commitment to a predictable release. I have no idea when to expect 0.14 or what breaking changes to expect until it’s released
snow swift
In practical, possibly pessimist, terms, that's true of software in general.
red dune
Not universally. Don’t get me wrong. I love and truly appreciate the work zig core folks do. I wouldn’t be here if I didn’t but I’m also coming from a world where there are regular release cadences that are both commitments and honored. Rust and Java to name a few. I consider this predictability a feature. I’m actually an optimist. I expect (and hope) zig to one day too will have regular releases and timelines that can be met.
lethal axle
Not universally. Don’t get me wrong. I love and truly appreciate the work zig co...
Just wanna chime in and say I agree with this fully. Zig (rightfully) gets away with a loose release cadence and "missed" deadlines because it's pre v1.0.
This will likely get reined in post release, but until then tracking the latest stable can be easier for library devs and anyone working on larger projects.
warm thunder
@red dune hey, i was just wondering, whats the reason behind using @memcpy in the decode function ? right now it's possible to panic the server by just adding more text to a jwt: panic: @memcpy arguments have non-equal lengths . a simple solution like
if (src.len != sig.len) {
return error.SignatureAndSourceLengthMismatch;
}
``` would work, but i am curious if theres a better way of handling it