Re: RC exception for net/py-twisted

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Schleifer <js%nil.im@localhost> writes:

> It seems that for net/py-twisted, there is a security issue which was
> fixed 2 weeks ago, but only in an RC. Some software such as
> chat/matrix-synapse have hence updated their dependency to require the
> rc1.
>
> I know we usually don't update software to RCs, but I'd like to
> propose that we make an exception for net/py-twisted, as they document
> that they do not do security releases:
>
>> We don’t do maintenance / patch releases, including for security
>>   issues, due to lack of resources.
>
> So because of that, they have released an rc1 2 weeks ago. But there
> is still no stable release with the fix. According to
>
> https://github.com/twisted/twisted/issues/12271
>
> this is because they don't have time to do enough testing so just want
> to keep the rc1 for a while.
>
> With that in mind, I think it's fair to say that it's an upstream
> which is broken enough to allow RCs in pkgsrc. I'd rather have an rc1
> than a release with known security issues that are trivial to
> exploit. For the stable branches, that of course is problematic, but
> I'd be nice to at least have the rc1 in trunk to fix this.

First, this is no longer relevant as twisted had a release and I updated
to the release (within an hour or so of it happening).

I object; upstream is merely a bit slower than you would like.  It's not
irretrievably broken.  The release was slower in part because there was
a regression in the first RC1, and that was fixed causing RC2.  This is
what RCs are for and this sort of RC/check/fix is healthy.

(As for twisted upstream, it is certainly a bit troubled.  I would
recomend to any package that depends on it that they need a get-well
plant to stop.  But that's off topic for this discussion.)

Looking at all the things we have in pkgsrc, twisted really doesn't
stand out as troubled.  I don't think it's enough to depart from "we
package releases only".

You have completely ignored how this should have been handled, which is
to backport the security fix to the previous release and apply it.
Nobody has tried, and we have no reason to think that would be
particularly difficult.  Probably Debian has done it by now and the
wisdom, if not the code, could be used.  So it's hard to take "this
security issue is terrible" seriously from someone who has not attempted
to backport the security fix.

Backporting the security fix also means that someone could submit a
pullup and fix the security issue on the stable branch.  Most users are
on the stable branch.

(Personally, the issue is not very serious to me, as the only package I
run that depends on twisted is configured in such a way that the bug
can't happpen, and I don't even know of anything that does use it in a
way that the bug can happen.  That doesn't mean it shouldn't be fixed,
but I don't think it rises to exceptional treatment, when "backporrt the
fix" and "wait what is really a pretty short time for a release" are
reasonable.)

Your rush to package an RC also ignores that we value both stability and
security, and that jumping to an RC skips the stability part.

You also didn't say that you have

  - packaged the RC in wip
  - tested something that uses twisted with it
  - asked for anyone else to try it (and that anybody who is super
    worried about security should make replace with it)

which would have been a way to reduce update risk and deliver the
security fix to people that want it.