I'm not familiar with development on macOS so I would appreciate any help in making sure that tlslite-ng continues to work there: tlsfuzzer/tlslite-ng#73 (in general, it should work as I try to use portable code, but it will be easier for you if the issues are caught early, not after release)

I don't think it's wise to leave a security-relevant package in that it is expected to remain unmaintained..
We should at least have a comment explaining why the package is broken (and should not be used), or perhaps alias the old package name over.

If the package is unmaintained and not used by anything, I don't think it should be in Nixpkgs at all. I'd prefer the derivation be deleted. It's never going to be fixed, (and in fact, since it's security-relevant, never should be fixed since it's unmaintained), so there's no benefit for us to continue to carry the code.

Thanks for the feedback. Personally I'd prefer to delete tlslite as well. As this change only affects master, I'd think we could delete it right away? People missing the package for their projects could be told (via the commit message), that they should use tlslite-ng. Or is there any mechanism like the deprecation warning for module options for packages?

I think the normal way to do this is to delete the package and then add an alias to throw “foo has been removed because bar. use baz instead”.

I’d prefer that we don’t just alias this to the ng version, because then it’s not clear what libraries a derivation is actually using.

I'll take the argument against aliasing, though if we end up having to backport for a security issue, it should get aliased over in the backport.
I can find some precedent (8 instances) in nixpkgs for throw "deprecated 2018-12-10: use tlslite-ng instead";

@GrahamcOfBorg build pythonPackages.tlslite-ng python3Packages.tlslite-ng