Maintainers for jsonrpclib-helix

[Moredread]

Issue description

At the moment the jsonrpclib-pelix package is only used by electrum and its derivatives. I'm mainly its maintainer as the package was needed as a dependency for those.

While I can keep an eye on keeping it up-to-date, I think it would be a good idea for the maintainers of electrum , electrum-ltc and electron-cash to also be maintainers of the jsonrpclib-pelix package, as I'm on one hand not comfortable to check it for security implications and on the other can't really test the ltc and cash variants atm.

Would it be OK to add you to the maintainers list, so you would be kept up-to-date with upgrades to that important dependency, @ehmry @joachifm @np @asymmetric @Lassulus?

[Moredread]

The latest PR is #54106 btw and still open.

[asymmetric]

Considering the recent security fiasco, I wonder if it even makes sense to package electrum and derivatives at all.

I’m not using them anymore so I’m not sure I’d want to take responsibility of a dependency.

[Moredread]

Yes that was quite bad. :/

I'm not sure I want responsibility for a package that is so security sensitive either atm.

[asymmetric]

Are there any precedents of removing a package due to its security track record being too low?

Is there any way to gauge usage?

[joachifm]

Re poor security track record: are there other bugs of similar or worse severity than this one, that were not adressed in a timely manner? Cursory searching yielded 2 other bad bugs, but that doesn't seem excessive. I think it's a little unfair to extrapolate from one bad bug to say the entire project should be abandoned. By that standard I don't think we could really use any software with much confidence.

[asymmetric]

That's a fair point. I guess my main concern are the derivatives, e.g. electrum-dash, which is unmaintained and likely using an insecure upstream version.

Also I'm not using (nor going to use) electrum-ltc anymore, so ideally I'd like to remove myself from the maintainers, leaving the package unmaintained.

[joachifm]

@asymmetric oh, I had no idea about the derivatives ... I certainly agree that packages of this nature lacking upstream should be marked insecure or even removed outright.

[asymmetric]

Turns out I was looking at the wrong repo for electrum-dash, this seems to be the correct one and it's being maintained apparently.

Regardless, the package in nixpkgs is hopelessly out of date and I think that unless someone feels responsible for updating it, it should be marked as unsafe (this is the CVE).

If we agree on this i can proceed to do the marking.

electrum-ltc is not vulnerable for that CVE, but still it's largely unmaintained (by me) - how should we proceed there?

[joachifm]

@asymmetric if you care to do the marking, that'd be great, IMO. I'm sure if someone cares about dash they'll resurrect the package in due time. I've no opinion on the ltc variant.

[c0bw3b]

@asymmetric marked electrum-dash as insecure in
a50507a -> master
48449d6 -> r19.09
3f92c21 -> r19.03

[asymmetric]

Thanks @c0bw3b, this slipped off my radar.