On 2022-03-01 15:37:42, Santiago Vila wrote:
> severity 1006633 important
> retitle 1006633 procmail is unmaintained upstream
I think that title is a mischaracterisation. Procmail is not just
unmaintained upstream, it's known to be insecure.
> Hi.
Hi,
> I could understand that we want to get rid of unmaintained software, but
> please do not inflate severities, at least while the discussion takes
> place and a consensus that the package should be removed has not been
> reached. This package is optional, and we are not forcing anybody to use
> it. If we had kept the extra priority, I would be glad to put it in
> "extra", but extra does not exist anymore.
I disagree with this assesment. If this was any leaf package with normal
permissions, I wouldn't mind. but procmail installs a SUID binary and,
because of that, should be subject to much stricter rules.
There were two bug reports asking for the SUID bit to be dropped or at
least be configurable (#298058, #264011), both of which were closed in
favor of dpkg-statoverride. But that, in my opinion, is not the right
mechanism: we should "fail closed" and default to a more secure option,
with the burden on the caller to enable a more dangerous option.
So this is not just some random package that's unmaintained. It's a key,
high profile security risk.
Also, I understand that we're not responsible for all the "guns" we ship
for people to "shoot in the foot" with. I get that. But this one doesn't
say anywhere on the tin that we're basically the upstream now.
> There are some things which need a clarification because they are not
> 100% accurate.
>
> El 1/3/22 a las 3:11, Antoine Beaupre escribió:
>> # unmaintained
>>
>> procmail is unmaintained. the "Final release", according to
>> Wikipedia[1], dates back to September 10, 2001 (3.22). this is the
>> release that is shipped with Debian, although we do have *26*
>> debian-specific uploads on top of that (3.22-26, in all suites since
>> buster).
>
> The Debian package is actually based on version "3.23pre" since version
> 3.22-21, dated 2013-10-15. I know this is a very minor correction, but I
> think it's important to state the facts right.
"3.23pre" doesn't really sound like a release at all to me...
> While it's true that procmail has not been maintained upstream for a
> long time, Debian is absolutely in his right to maintain its own version
> without an upstream, that's one of the properties of free software.
Sure. We have every right to ship dead and unmaintained software if we
really, really want to. My argument is that we *shouldn't*.
>> the last maintainer of procmail explicitly advised us (in #769938) and
>> other projects (e.g. OpenBSD, in [2]) to stop shipping it.
>
> Same as before, Debian is in his right to follow this advice or not.
Yes, but is it *right* to ignore it? I strongly doubt that.
I'm not making a legal argument here. I'm making an ethical argument:
procmail is unmaintained and insecure, and we shouldn't ship it.
There are plenty of programs we remove from Debian because they are
unmaintained upstream, even *without* being insecure. That's fine. We
are a free software clearing house, not a dump.
>> That Debian bug report is still open, and concerns a NULL pointer
>> dereference.
>
> I've just make an upload to fix such bug.
I'm sorry, but the fact that it took over 7 years to do this is
telling. That bug isn't fixed upstream, for example.
> Debian security people: Is there a CVE for Bug #769938? Maybe this
> should backported for stable as well.
>
>> I do not know if it is exploitable. Strangely, the
>> original procmail author (Stephen R. van den Berg, presumably) wrote
>> in that bug report *last year* saying that was "Fixed in upcoming 3.23
>> release", which has been targeted for release for all of those last 20
>> years.
>
> I guess he did not refer to the version which was "upcoming 20 years
> ago", but to the git version on which he was working in the last years.
But the 3.22-1 upload explicitly refers to that 3.23pre release:
procmail (3.22-1) unstable; urgency=low
* New upstream release, which uses the `standard' format for Maildir
filenames and retries on name collision. It also contains some
bug fixes from the 3.23pre snapshot dated 2001-09-13.
* Removed `sendmail' from the Recommends field, since we already
have `exim' (the default Debian MTA) and `mail-transport-agent'.
* Removed suidmanager support. Conflicts: suidmanager (<< 0.50).
* Added support for DEB_BUILD_OPTIONS in the source package.
* README.Maildir: Do not use locking on the example recipe,
since it's wrong to do so in this case.
-- Santiago Vila <sanv...@debian.org> Wed, 21 Nov 2001 09:40:20 +0100
That's what I'm refering to. The existence of 3.23pre was manifest all
the way back in 2001, unless that changelog is inaccurate.
So I think it's fair for me to assume that there's a good chance that
3.23 will never see the light of day, especially since the procmail.org
homepage is dead.
Where would it even be released?
> In either case, I'm Cc:ing Stephen, who some time ago was preparing a
> release which included all the Debian fixes so far.
>
> Stephen: If you intend to release a new procmail version, please do so.
I'm sorry if I'm beating a dead horse here, but this is just the tip of
the iceberg. My understanding of the current situation is that anyone
running AFL long enough for procmail will find further major security
issues and that will take an untold amount of time to fix.
The fact that we had a possibly exploitable NULL deref open for 7 years
and shipped in two release is already alarming enough. We shouldn't keep
doing this and stop shipping this in stable releases.
Do we really need someone to go through with this process and flood this
bugtracker with fuzzer bugs to prove that point?
If you want to keep procmail in Debian, please at least keep it away
from stable.
Thanks.
a.
--
Sous le projecteur, on ne voit pas les autres.
- Félix Leclerc
