Closed andrewbaxter closed 8 months ago
I have a question about the library, and I feel bad about putting it in the issue tracker. Would it be reasonable to enable the discussions tab?
I am open to enabling some kind of discussion platform so that users can more easily help each other out. Besides GitHub Discussions there's also zulip and slack and whatnot. I'm not sure which kind of forum is best and would appreciate suggestions and then help with getting it going.
Regardless, if you think an API is confusing or underdocumented or plain wrongly-structured or whatnot, that's definitely worthwhile of an issue.
Rather than address your specific question, which is off-topic for this issue (which is about enabling discussions): I created a new issue at https://github.com/briansmith/ring/issues/1889. I suggest you comment over there. I am curious about your thoughts.
GitHub discussions is okay. For rustls we've opted to create a Discord channel on a Discord server that I started which also contains channels for a bunch of other crates. I'd be happy to create a channel for ring if you'd like.
IMO there are some advantages to a more chat-style thing vs a forum-style thing. I feel like chat-style things enable more free-form discussion and sometimes make discussion feel less like a chore and more social and can lower the barrier to entry (leading to more feedback which I've often found useful). Among the chat-style options I think the main alternative is Matrix, but I've felt its UX to be substantially worse than Discord. Slack has more of a corporate feel and is not usually used for non-commercial open source projects that I've seen. Zulip is maybe sort of a cross-over between chat and forum-style options, but it has the downside that it requires a separate user account per server (and I don't think there's an obvious existing server that ring could join).
In any case, I think Discord has worked out nicely for rustls, and there might be some advantages to colocating.
I'm in a weird timezone and often tied up doing other things so I tend to be asynchronous, posting and coming back to the discussion hours or days later. Also Discussions doesn't need an extra account (if you're already on github) and being able to compose in a larger markdown editor can be nice. My main thought with Discussions is if people post there initially it could reduce noise in Issues.
But I think they might have different use cases... getting stuck, or more immediate problems vs longer term things, or collaboration and bouncing ideas around, etc. I'm aware there's a bit of a war on discord vs forums... but I guess depending on your community appetite it might make sense to have both.
Oh I see Discussions is enabled now... not sure how to read that :sweat_smile:
I guess it doesn't hurt to turn it on? I appreciate it in any case, if you decide to go with something else though feel free to close any posts of mine there.
Oh I see Discussions is enabled now... not sure how to read that 😅
We can try it and see what happens. Maybe more people will feel comfortable talking in the discussions than in the issue tracker.
@djc wrote:
IMO there are some advantages to a more chat-style thing vs a forum-style thing. I feel like chat-style things enable more free-form discussion and sometimes make discussion feel less like a chore and more social and can lower the barrier to entry (leading to more feedback which I've often found useful).
Definitely I would like to interact more with the people working on and using Rustls but I never find the time to log into the Discord. When all projects have their own chatrooms, especially on different services, it becomes a chore to just switch from one chat to another. I really like just having a single inbox (my email) that everything gets funneled to, and where the default assumption is that communication is highly async.
I have a question about the library, and I feel bad about putting it in the issue tracker. Would it be reasonable to enable the discussions tab?
Here's the question in case the answer to the above is "no":
signature::EcdsaKeyPair::from_pkcs8
requires specifyingalg
. AFAICT ECDSA private keys in PKCS#8 format contain the algorithm identifier which includes the both the curve and any additional parameters. Why is the algorithm a parameter rather than use the information stored in the key?Additionally, and I feel like I'm way out of my depth here,
ec::suite_b::key_pair_from_pkcs8
doesn't look like pkcs8 as I understand it. The code extracts a header (1), then the private key, then the algorithm which looks like the SEC1 ASN.1 encoding, whereas PKCS8 has version (0), then the algorithm, then the private key. But I guess whether it's PKCS#8 or SEC1 it includes the algorithm identifier with curve information.