Good questions, they’re very general – here’s my (unofficial) recommendations. I’m still gaining lots of experience with these kinds of things, so take these at face value (“use at your own risk” kind of thing). But if nothing else it might be something to think about or consider more deeply.
I’m not really sure what you mean by this; but if you find a vulnerability, typically disclose it privately until it’s fixed and deployed (if applicable). If you are talking about the other way around, be conservative when taking on new dependencies – you get code for free, yes, but you also are taking a risk that the upstream library might stop being developed or be found to be vulnerable or even compromised (owner’s password is guessed and doesn’t have 2FA, etc.). If worse comes to worst, fork the upstream, fix it yourself, and update your own software. Either that or find a different dependency that doesn’t have the same problem and switch.
Do it at the right time: make sure you know as much about the issue as you can. Be real. Make the length of the communication proportional to the severity of the issue. If you produce a 5-page writeup about something that’s not a big deal or only affected ~1% of users, there might still be technical value there, but it might also scare a lot of people unnecessarily.
As in, how do you encourage people to update? Do your best to communicate the new version is available and why people should update (without overreacting of course). A casual, but professional, tone is more approachable and will intrigue more people and invite them to update. I think auto-update mechanisms (like what browsers have), when done properly, have extreme value here. But they’re hard to do right. I maintain a mailing list with basic information about updates and always refer people to the full release notes. (Also, pre-1.0 might be different than post-1.0; with pre-1.0 I expect people to always read release notes. And I try to communicate that. Post-1.0, users should be able to trust that 1.1.2 → 1.1.3 won’t break them.)
With Caddy, we adopt new protocol versions as soon as possible for their security and performance merits. If they’re not yet stable or totally reliable, we make them opt-in (like QUIC currently is). We remove old/broken ones immediately and without regard for old clients. It’s harsh, but hitting the ground running like this we might be able to pull it off. We do keep some selected old cipher still available if users really want to enable them, but we discourage it in the docs… you kind of have to find the right balance. Even post-1.0, I’m betting our compatibility guarantee will make an exception for security protocols.
Nope, in Caddy, some TLS features can’t be changed by the user. For example, we don’t let them remove TLS_FALLBACK_SCSV from the cipher suites.
And yeah, these are all hard problems. A lot depends on your situation; your goals, how important security vs. productivity, usability, customizability, etc. are to you.
So you can ask here if you’d like.